Temporal API 能彻底解决夏令时误差，但需严格分离日历时刻与时区解释：用 PlainDateTime 解析输入、显式结合时区生成 ZonedDateTime，避免静默错位；跨时区操作须统一转 ZonedDateTime 后比对纳秒值，且创建时必须同时提供偏移量与时区名（如[Asia/Shanghai]）。
Temporal API 能彻底解决夏令时切换导致的时间误差，前提是不把 ZonedDateTime 当作 Date 的增强版来用——它要求你显式声明“日历时刻”和“时区解释”的分离，否则照样出错。
为什么 new Date('2026-03-09T02:30') 在美国东部时间会静默错位
这个字符串在 America/New_York 时区的 2026 年 3 月 9 日凌晨根本不存在（DST 开始日，钟表从 2:00 直跳 3:00）。Date 会静默调整为 3:30 或回滚到前一小时，且不报错；不同浏览器解析结果可能不一致。这不是 bug，是设计缺陷：它只存毫秒戳，却在构造/格式化时偷偷绑定本地时区。
实操建议：
- 所有用户输入的时间（如表单）必须先用
Temporal.PlainDateTime.from()解析，仅校验日历合法性（比如 2 月 30 日直接抛RangeError），不涉及时区 - 再结合用户选择的时区（如
'America/New_York'）调用.toZonedDateTimeISO(timeZone)，让 Temporal 查 IANA 数据库确认该时刻是否真实存在 - 若传入模糊时间（如夏令时重叠的
2026-11-02T01:30），默认用disambiguation: 'compatible'（取后一个偏移），可显式设为'earlier'或'later'
add() 和 withTimeZone() 在 DST 边界的行为差异
add({ hours: 24 }) 是沿时间轴推进固定时长，全程保持原始时区上下文；withTimeZone('Europe/London') 是瞬时转换，会重新查目标时区在该 UTC 时刻的偏移。二者不能互换，混淆会导致会议提醒提前或延后一小时。
例如，从 2026-03-08T23:00-05:00[America/New_York] 执行 .add({ days: 1 })，得到的是次日同一本地时刻（即 3 月 9 日 23:00 EDT）；而用 .withTimeZone('Europe/London')，会立刻查 2026-03-09T04:00Z 在伦敦是 BST(+01:00)，返回 2026-03-09T05:00+01:00[Europe/London]。
关键点：
- 跨时区比较必须统一转成
ZonedDateTime，再用.getEpochNanoseconds()比较数值，避免.equals()因时区不同返回false却实际指向同一时刻 - 生成前端显示用的本地时间，别用
toLocaleString()（受系统设置影响），改用zdt.withTimeZone('local').toString() -
Temporal.Now.zonedDateTimeISO()返回的是系统默认时区的ZonedDateTime，不是 UTC；要 UTC 请用Temporal.Now.instant()
创建 ZonedDateTime 时漏掉方括号时区名会直接 TypeError
Temporal.ZonedDateTime.from('2026-04-21T14:00+08:00') 会抛 TypeError，因为 +08:00 是静态偏移，无法表达时区的历史与未来变化（比如中国 1986–1991 年曾实行夏令时，偏移是 +09:00）；而 [Asia/Shanghai] 是动态时区标识，Temporal 会按时间点自动查表匹配偏移。
正确写法必须带方括号：
- ✅
Temporal.ZonedDateTime.from('2026-04-21T14:00+08:00[Asia/Shanghai]') - ✅
Temporal.ZonedDateTime.from({ year: 2026, month: 4, day: 21, hour: 14, timeZone: 'Asia/Shanghai' }) - ❌
Temporal.ZonedDateTime.from('2026-04-21T14:00+08:00')（缺时区名） - ❌
Temporal.ZonedDateTime.from('2026-04-21T14:00[Asia/Shanghai]')（缺偏移量，解析失败）
注意：即使偏移量看起来“对得上”，也必须同时提供，这是强制校验机制的一部分。
最易被忽略的点是：Temporal 不是“更聪明的 Date”，它是另一套范式。一旦你用 PlainDateTime 表达“某地早上 9 点开会”，就必须用 TimeZone 显式解释它——不能指望任何自动推导。夏令时边界问题不会消失，但会从“静默错位”变成“明确报错”，而报错的位置，就是你该加业务逻辑的地方。
