DATE_TRUNC更可靠因自动适配各数据库周起点规则，避免手动计算的边界错误；跨平台需查文档确认行为，统一周一为周首时BigQuery需调整函数，Redshift无需改动。
DATE_TRUNC 为什么比手动计算周起止更可靠
直接用 DATE_TRUNC('week', order_time) 得到当周周一（PostgreSQL / BigQuery）或周日（Redshift），比自己写 order_time - INTERVAL '1 day' * EXTRACT(DOW FROM order_time) 少踩日期边界坑。不同数据库对“一周起点”的定义不一致：PostgreSQL 默认周日为起点，但设置 lc_time='C' 或显式指定 'week_sunday' 才能统一；BigQuery 始终以周日为起点，DATE_TRUNC('week', t) 返回的是包含 t 的那个周日；Redshift 则默认周一为起点，且不支持自定义——所以跨平台迁移时，必须查文档确认行为，不能假设一致。
常见错误是把 DATE_TRUNC('week', order_time) 当作“本周一”，结果在 Redshift 里它真就是周一，在 BigQuery 里却是周日，导致分组错位。如果业务要求统一按周一为周首，BigQuery 要改用：DATE_TRUNC(DATE_SUB(order_time, INTERVAL 1 DAY), WEEK(MONDAY))；Redshift 则无需调整。
DATEADD 配合 DATE_TRUNC 实现动态周期偏移
想统计“最近 4 周每周销售额”，不能只靠 GROUP BY DATE_TRUNC('week', order_time)，还得过滤时间范围。这时用 DATEADD 比手写 order_time >= '2024-01-01' 更灵活：WHERE order_time >= DATEADD('week', -4, DATE_TRUNC('week', CURRENT_DATE))。注意参数顺序：Redshift 和 Snowflake 是 DATEADD(unit, number, date)，而 BigQuery 是 DATE_ADD(date, INTERVAL number unit)，函数名和参数位置都不同。
容易忽略的点：
-
DATEADD('month', 1, '2023-01-31')在多数引擎中返回'2023-02-28'（非报错），但DATEADD('quarter', 1, '2023-01-31')可能变成'2023-04-30'—— 月末逻辑会自动归整，不是简单加天数 - 用
DATEADD做月度同比时，DATEADD('year', -1, order_month)比order_month - INTERVAL '1 year'更安全，后者在某些方言中可能触发类型隐式转换失败 - 季度分组别硬写
CASE WHEN EXTRACT(MONTH FROM order_time) IN (1,2,3) THEN 'Q1'...，直接DATE_TRUNC('quarter', order_time)更简洁，且天然处理跨年季度（如'2023-12-15'→'2023-10-01'）
按月分组时要注意时区与截断粒度
DATE_TRUNC('month', order_time) 看似简单，但实际执行依赖会话时区。比如订单时间存的是 UTC，但你的查询会话设了 timezone = 'Asia/Shanghai'，那 DATE_TRUNC('month', order_time) 会在本地时区截断——'2024-01-01 01:00:00+00' 在上海时区是 '2024-01-01 09:00:00+08'，截断后仍是 '2024-01-01'；但 '2024-01-01 00:30:00+00' 在上海是 '2024-01-01 08:30:00+08'，也没问题。真正出问题的是 '2024-01-01 00:00:00+00' —— 它在上海是 '2024-01-01 08:00:00+08'，仍属同月；但 '2023-12-31 16:00:00+00' 在上海是 '2024-01-01 00:00:00+08'，会被误判进 2024 年 1 月。
解决方案只有两个：
- 所有时间字段先转成目标时区再截断：
DATE_TRUNC('month', order_time AT TIME ZONE 'Asia/Shanghai') - 或者统一用 UTC 截断，报表层再换算显示月份（更推荐，避免聚合阶段时区污染）
另外，DATE_TRUNC('month', ...) 返回的是 DATE 类型（如 '2024-01-01'），不是字符串，别在 GROUP BY 里再套 TO_CHAR(..., 'YYYY-MM') —— 多余转换且影响索引下推。
季度分组别漏掉 YEAR 字段导致跨年混乱
只用 DATE_TRUNC('quarter', order_time) 分组，结果可能是：'2023-10-01'、'2024-01-01'、'2024-04-01'……看起来没问题。但一旦做环比（比如 Q1 2024 vs Q4 2023），你得确保排序是按真实时间顺序，而不是字典序——'2023-10-01' 字典序小于 '2024-01-01'，但时间上是之后。所以建议分组字段显式带上年份维度：EXTRACT(YEAR FROM order_time) AS year, EXTRACT(QUARTER FROM order_time) AS quarter，或直接用 TO_CHAR(order_time, 'YYYY-Q')（PostgreSQL / Redshift），这样既能排序又能读。
还有一点常被忽略：不同数据库对 QUARTER 的提取逻辑一致（1~4），但 DATE_TRUNC('quarter', ...) 的返回值精度不同。Snowflake 返回 TIMESTAMP_NTZ，Redshift 返回 DATE，BigQuery 返回 DATE；如果后续要 join 其他表的日期字段，类型不一致会强制 cast，可能丢精度或报错。
最麻烦的其实是“财年季度”——比如财年从 4 月开始。这时 DATE_TRUNC 无解，必须用 CASE 或自定义函数映射：把 4~6 月算 Q1，7~9 月 Q2……否则所有标准函数都按自然年切分。
