· 全部指南
为什么计算机都用UTC时间
协调世界时（UTC）是互联网的通用语言，它不依赖时区且无视夏令时。当服务器日志显示'2023-11-20T08:00:00Z'时，末尾的'Z'代表零时区，这是开发中唯一可信的时间基准。使用Towalles的time-converter工具时，所有计算都在浏览器本地完成，您的敏感时间数据不会上传到任何服务器。
常见误区是将UTC与GMT混为一谈。虽然二者在大多数情况下显示相同时间，但GMT是天文概念而UTC基于原子钟。在要求高精度的时间戳场景（如金融交易系统）中，这个差异可能造成微秒级误差。
时区数据库的暗礁
全球200多个时区并非简单偏移：阿拉斯加部分地区使用UTC-9但夏令时切换日期与邻州不同。使用Towalles的world-time工具时，它会自动加载最新的IANA时区数据库，但要注意政治因素导致的变更——比如2019年摩洛哥突然将夏令时推迟一周。
开发中应始终使用时区全名（如'Asia/Shanghai'）而非缩写（如'CST'），因为后者可能对应多个时区。处理历史数据时更要小心：俄罗斯在2014年后永久停止使用夏令时，但此前的数据仍需特殊处理。
夏令时的反直觉陷阱
夏令时切换会产生25小时或23小时的异常日。2023年北美夏令时结束于11月5日01:59:59，下一秒直接跳回01:00:00。处理这类边界值时，推荐使用Towalles的date-converter进行可视化校验，该工具会以不同颜色标注出可能存在问题的时间段。
航空公司系统最易受夏令时影响。伦敦-纽约航班在10月29日可能显示7小时飞行时间，但实际经历6小时，因为欧洲和北美夏令时结束日期不同。开发预订系统时务必使用包含TZ信息的ISO8601格式（如'2023-10-29T15:00:00+01:00'）。
国际日期变更线的开发启示
当萨摩亚在2011年12月30日跳过整个12月31日时，所有基于'当前日期'的订阅系统崩溃了。处理跨越日期线的业务（如太平洋岛国电商）时，应在业务逻辑层显式处理日期差，而非依赖系统时钟。world-time工具的地图视图可以清晰展示这种特殊案例。
API设计黄金法则：对外永远返回UTC时间戳（带Z标识），对内存储时区原始值。例如用户选择'2023-06-15 08:00 Sydney时间'，应存储为'2023-06-14T22:00:00Z + Australia/Sydney'两字段。这样既保证计算一致性，又保留原始意图。
存 UTC，显示本地
时间戳以 UTC（或带偏移类型）持久化，在边缘转成查看者时区。不要用「减 8 小时」代替 Asia/Shanghai——夏令时与政策变化会让硬编码失效。
重复事件
日历计算需要感知时区的库。在 DST 切换点用 fixture 测试，而不只测盛夏「快乐路径」。
API
在载荷中明确时区（2026-07-20T15:00:00+08:00 或独立 tz 字段）。回拨小时的歧义本地时间要有政策。
排障
两套系统相差一小时时，比较 zone ID 与 DST 规则库是否过期——不要只看时钟偏差。
时区事故处理
动生产前先写操作程序：输入、期望输出、负责人与回滚。Towalles 上的工具便于本地检查样例，不能替代变更控制。
前置条件
- 有代表失败案例的脱敏 fixture。
- 清楚谁是真相来源（应用、网关、CMS 或网络设备）。
- 能在非生产环境或用合成数据复现问题。
步骤
- 用 fixture 复现，记录精确命令或 UI 路径。
- 按需用格式化、哈希或解析工具与已知正确样例对照。
- 做最小修复；同一变更里避免顺手重构。
- 补充回归测试或清单项，避免下一任 on-call 重复踩坑。
- 更新 runbook：症状 → 检查 → 修复。
善后
观察 24–72 小时错误率与支持工单。若做过一次性数据修复，安排后续防止复发。工单里保留截图与哈希，不要留真实密钥。
反模式
- 把生产密钥贴到公开页面「只是看一下」。
- 上线却不写回滚说明。
- 把本地绿色演示当成多区域生产的证明。