编程中的 UTC 转换 - 处理时区的正确模式

以 UTC 存储,以本地时间显示

处理时间戳最重要的一条法则是: 一律以 UTC 存储,仅在向用户展示时才转换为本地时间。违反此规则的系统会在夏令时边界产生微妙的 bug,并且在扩展到第二个时区时彻底崩溃。每个团队终究会重新学到这个教训,往往是在一次生产事故之后。

UTC 没有夏令时,且单调递增,这正是存储数据所需要的特性。以本地时间存储会引发秋季夏令时切换时的“两个 1:30 AM”问题: 在纽约,挂钟时间 1:30 AM 会出现两次 - 一次是 EDT (UTC-4),一次是 EST (UTC-5),而存储的 1:30 AM 无法区分是哪一次。UTC 通过记录“那个时刻”而非“挂钟读数”,完全避开了这个问题。

ISO 8601 - 真正携带时区信息的字符串格式

当时间戳必须序列化为文本时,请使用 ISO 8601 (例如 2026-05-15T07:00:00Z)。尾部的 Z 表示 UTC,而 +09:00 这样的显式偏移量表示特定的本地时区。关键在于必须包含时区信息。一个不带偏移量的 2026-05-15T16:00:00 是模糊的,任何消费者在解析时都会做出时区假设。

在数据库存储方面,PostgreSQL 的 TIMESTAMP WITH TIME ZONE (timestamptz) 是最简洁的选择; 它在内部始终以 UTC 存储,读取时转换为会话的时区。MySQL 的 TIMESTAMP 底层也以 UTC 存储。而无时区的 TIMESTAMP WITHOUT TIME ZONE 列则需要应用程序仅靠纪律来执行 UTC 约定,当团队更替或新增代码时,这种约定最终必然失败。

JavaScript 和 TypeScript 中的模式

JavaScript 的 Date 对象内部以“自纪元起的 UTC 毫秒数”表示时间。toString() 和 toLocaleString() 等方法按运行时的本地时区显示,该时区由浏览器设定或通过 Node.js 的 TZ 环境变量设置。对于服务器应用,在生产环境中设置 TZ=UTC 可以消除日志时间戳的猜测,并使服务器行为不受主机位置的影响。

使用 Intl.DateTimeFormat 配合 timeZone 选项可进行任意时区的格式化。指定 IANA 名称 (如 America/New_York) 会自动处理夏令时切换。手动计算偏移量是不明智的,因为夏令时规则经常变化; 依赖操作系统或运行时内置的 IANA 数据库才是唯一可持续的做法。

最常见的时区 bug

最常见的 bug 是错误处理纯日期字段。将生日存储为 1990-03-15 并用 new Date('1990-03-15') 解析,某些浏览器会将其解释为 UTC 午夜,导致 UTC-5 的用户看到的是 3 月 14 日。纯日期数据应当添加一个 UTC 正午时间分量 (T12:00:00Z) 以避免跨日,或者在格式化之前保持字符串状态。

紧随其后的常见问题是以本地时间配置定时任务。在春季夏令时切换日,安排在 2:30 AM 的任务会被跳过,因为那天 2:30 根本不存在;在秋季切换日,1:30 AM 的任务会执行两次。用 UTC 定义调度计划并以 UTC 记录时间戳,即使偶尔需要在阅读日志时做心算转换,也能完全消除这类问题。

时区代码的测试策略

时区代码的测试至少应覆盖: UTC+0 (伦敦冬季)、正偏移 (东京 UTC+9)、负偏移 (纽约 UTC-5)、30 分钟偏移 (印度 UTC+5:30)、夏令时切换边界、国际日期线跨越,以及年末日期翻转。以上每一项都可能单独击溃在日常测试中看似正确的代码。

还要注意 CI 环境的时区。如果开发者本地使用 UTC+9 而 CI 运行在 UTC,测试可能本地通过但 CI 中失败,且原因不明显。稳健的做法是让被测函数接受时区作为参数 (或在测试中通过常量冻结时区),消除对运行时环境的依赖。使用 fast-check 或 hypothesis 等库进行基于属性的测试,可以生成你可能遗漏的边界情况。