一、UTC 与偏移量
世界以 UTC（协调世界时）为基准，各地用「UTC + 偏移」表示本地时间：
| 地区 | 偏移 | 说明 |
|---|---|---|
| 中国 | UTC+8 | 全国统一，无夏令时 |
| 日本 | UTC+9 | |
| 印度 | UTC+5:30 | 半小时偏移 |
| 尼泊尔 | UTC+5:45 | 45 分钟偏移 |
| 英国（冬令时） | UTC+0 | 夏令时变 UTC+1 |
| 美国东部（冬令时） | UTC-5 | 夏令时 UTC-4 |
不是所有偏移都是整小时，印度、尼泊尔、部分澳大利亚地区是半小时或 45 分钟，写死「整点偏移」的代码会出错。
二、别用缩写，用 IANA 名称
时区缩写歧义严重：
- CST：中国标准时间（UTC+8）、美国中部标准时间（UTC-6）、古巴标准时间（UTC-5）。
- IST：印度、爱尔兰、以色列。
- BST：英国夏令时、孟加拉标准时间。
正确做法是用 IANA 时区数据库的名称：
Asia/Shanghai
Asia/Tokyo
America/New_York
Europe/London这些名称带完整的夏令时规则，跨年计算也准确。Asia/Shanghai 和 Asia/Chongqing 现在等价，但用 Asia/Shanghai 更通用。
三、夏令时（DST）
实行夏令时的地区，每年两次调整时钟：
- 春季「拨快一小时」，当地时间 2:00 直接跳到 3:00，这一小时不存在。
- 秋季「拨慢一小时」，1:00–2:00 出现两次，这一小时重复。
影响：
- 那两天的「几点」映射到 UTC 不是唯一/不存在的。
- 定时任务如果按本地时间触发，可能漏跑或跑两次。
- 跨时区排会，要说明是「本地时间」还是「UTC 时间」。
中国不实行夏令时，但做国际业务（尤其涉及欧美用户）必须处理。
四、跨时区排期的做法
- 统一用 UTC 沟通：给出「UTC 07:00」，再附上各自本地时间。
- 给出具体日期 + 时区名：
2026-11-10 15:00 Asia/Shanghai，不要只写「下午三点」。 - 用日历工具：Google Calendar / Outlook 会自动换算，但前提是双方时区设置正确。
- 注意日期可能不同：UTC 07:00 在中国是当天 15:00，在美国西部是前一天 23:00。
排会前先算一遍，比开会时发现有人缺席强。
五、ISO 8601 格式
2026-11-03T10:00:00+08:00 带偏移，明确
2026-11-03T02:00:00Z 末尾 Z 表示 UTC
2026-11-03 仅日期推荐：
- 存数据库用 UTC（
TIMESTAMP或带时区的类型）。 - 接口传输用带偏移的 ISO 8601，或明确约定「均为 UTC」。
- 展示时按用户时区转换。
反面例子：2026-11-03 10:00:00 不带时区，谁都不知道这是哪里的 10 点。这种「naive datetime」在跨系统对接时必然出问题。
六、服务器统一 UTC 的好处
- 日志时间一致，跨机器排查不用换算。
- 数据库存储无歧义。
- 定时任务按 UTC 定义，不受夏令时影响（但业务上要按用户时区触发时另说）。
展示层再用前端或模板按用户时区格式化。「存 UTC，显示本地」是通用原则。
七、几个常见坑
new Date('2026-11-03')按 UTC 解析，在东八区显示为 08:00，做「纯日期」比较时会错一天。- 数据库
TIMESTAMP会自动转换（按会话时区），DATETIME不会。跨时区部署时行为不同。 - Excel 不带时区，多人协作时容易误解。
- 跨年跨月：UTC 12 月 31 日 20:00 在东八区已是次年 1 月 1 日 04:00，年份都变了。
八、工具
用 时区转换工具 可以同时看多个城市的对应时间；把时间戳转成各地时间用 时间戳转换；算跨时区的日期差用 日期计算。
小结
用 IANA 名称（Asia/Shanghai）而不是 CST 这类缩写；夏令时会导致某小时不存在或重复；排期要写清时区；存储用 UTC、展示转本地；纯日期不要用时间戳运算。