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()行为本质不同，容易在状态更新逻辑里漏掉赋值
