时区与日期语义规范
时间字段的时区语义必须在存储层固定：常见两种做法，一是统一用 UTC 存储、展示或按业务日切分时再转换，二是全链路统一到一个业务时区（如 Asia/Shanghai）。选哪种都要在字段注释与建模文档里显式声明，否则同一批数据会被不同团队按不同日期汇总，差异集中出现在日界附近。
基本信息
| 策略 A | UTC 存储加展示转换 |
|---|---|
| 策略 B | 全链路单一时区 |
| 要求 | 字段注释与文档声明 |
| 风险点 | 跨时区数据集结 |
| 日切 | 业务日界线需固定 |
典型使用场景
- 新建时间字段时即声明时区语义，避免各团队按本地时间各自解释
- 海外业务按当地日期统计：先转当地时区再取日期，不要直接用 UTC 日期
- 日结任务确定日切点：对齐上游日切时间，避免两个日期的数据落在同一个任务里
- 跨时区对比：把两地时间换算到同一基准时区，再按同一业务日比较
- 与业务系统对数前先确认双方时区基准，否则差异全落在日界附近
时区转换
时区转换
-- 存储为 UTC，展示或切业务日时再转换
SELECT from_utc_timestamp(create_time_utc, 'Asia/Shanghai') AS create_time_local,
to_date(from_utc_timestamp(create_time_utc, 'Asia/Shanghai')) AS order_date
FROM dwd_trade_order_di
WHERE dt = '2026-10-12';
-- 与外部系统对齐时统一用 UTC 列比较，避免各自本地时间直接相减时区策略对照
| 策略 | 优点 | 代价 |
|---|---|---|
| UTC 存储 | 跨系统对齐简单，海外一致 | 每次查询都要转换，容易被漏掉 |
| 单一业务时区 | 报表直接可读 | 跨时区业务仍需额外换算 |
| 两种混用 | 无 | 日界错位，最难排查 |
日结业务按时区切分时，UTC 日期与业务日期会差一天；日切口径不固定，跨日界的订单会被分别算进两个日期，报表与业务系统永远对不上。
建议时间戳列存 UTC 并在名字上带 _utc 后缀，本地业务日期另设独立字段；同一个字段承载两种语义是时区类问题的主要来源。