temporal 是对 date 的彻底替换而非修补，通过解耦时区、日历、精度与不可变性，使跨时区及夏令时处理从经验驱动变为类型安全的构造器选择。

Temporal 提案不是对 Date 的修补，而是彻底替换——它把时区、日历、精度、不可变性这些关键维度全部解耦，让跨时区与夏令时处理从“靠经验踩坑”变成“按类型选构造器”。

为什么 Date 在夏令时切换日必然出错

Date 内部只存毫秒时间戳（UTC），但构造和格式化时又隐式绑定本地时区。当系统时区在夏令时切换日（如 3 月第二个周日）执行 new Date('2024-03-10T02:30')，这个时间在北美东部时间（EST→EDT）根本不存在（钟表从 2:00 直跳 3:00），Date 会静默调整为 3:30，且不报错、不提示。

• 所有基于字符串解析的构造（new Date(string)）都依赖宿主环境实现，Chrome 和 Safari 对同一字符串可能产出不同结果
• Date.prototype.toLocaleString() 的输出受用户系统设置影响，无法稳定用于日志或 API 序列化
• 没有原生方法能告诉你“2024-11-03 01:30 在 America/Chicago 是标准时间还是夏令时间”

Temporal.PlainDateTime 与 Temporal.ZonedDateTime 的分工逻辑

前者只管“日历日期+时间”，后者才真正承载“某时区下的确定时刻”。二者不可混用，也绝不自动转换。

• Temporal.PlainDateTime.from('2024-11-03T01:30')：仅校验日历合法性（如 2 月 30 日会抛 RangeError），不涉及时区，也不判断是否处于夏令时
• Temporal.ZonedDateTime.from('2024-11-03T01:30-05:00[America/Chicago]')：必须带 IANA 时区名，会查 tzdata 确认该时刻对应 UTC 偏移（-06:00 或 -05:00），并记录 timeZone 和 offset 字段
• 若传入模糊时间（如夏令时重叠时刻 2024-11-03T01:30），ZonedDateTime.from() 默认用 disambiguation: 'compatible'（取后一个偏移），可显式设为 'earlier' 或 'later'

处理夏令时边界时刻的实操模式

核心原则：不解析模糊字符串，不依赖本地时区，所有转换显式声明策略。

• 接收用户输入的时间（如表单）→ 先用 Temporal.PlainDateTime.from() 解析，再结合用户选择的时区（如 'Europe/Berlin'）调用 .withTimeZone() 转为 ZonedDateTime
• 比较两个不同时区的时间 → 必须先转成 ZonedDateTime，再用 .getEpochNanoseconds() 比较数值，避免 .equals() 因时区不同返回 false 却实际指向同一时刻
• 生成供前端显示的本地时间 → 不用 toLocaleString()，而用 zdt.withTimeZone('local').toString()，确保逻辑可控
• 注意 Temporal.Now.zonedDateTimeISO() 返回的是系统默认时区的 ZonedDateTime，不是 UTC；要 UTC 时刻请用 Temporal.Now.instant()

兼容性与落地注意事项

Chrome 119+、Firefox 120+、Safari 17.4+ 已支持 Temporal，但 Node.js 需 v20.12+ 且启用 --harmony-temporal 标志。生产环境仍需兜底。

• 不要直接替换所有 Date 实例——旧代码中大量 getTime()、toISOString() 调用无法无缝迁移
• 第三方库（如 date-fns-tz）尚未适配 Temporal，混合使用时注意 ZonedDateTime 到毫秒时间戳需调用 .epochMilliseconds，而非 .getTime()
• 服务端若需序列化，优先用 .toString()（ISO 8601 扩展格式），避免 .toJSON()（仍走旧 Date 逻辑）
• 最易被忽略的一点：Temporal 的所有类型都是不可变的，.with({hour: 14}) 返回新实例，原实例不变——这和 Date 的 setHours() 行为本质不同，容易在状态更新逻辑里漏掉赋值