temporal不能完美解决时区与夏令时问题，但能将错误显式暴露而非静默出错，从而实现真正可维护的时间处理。
Temporal 不能“完美解决”时区与夏令时问题，但它能让你把错误显式暴露出来、不再静默错——这才是真正可维护的起点。
为什么 Date.prototype.getTimezoneOffset() 总是返回“当前偏移”，而不是“那个时刻的偏移”
Date 对象内部只存一个毫秒数（自 Unix 纪元起），构造时的 getTimezoneOffset() 值会被固化，但后续调用 toLocaleString() 或解析字符串时，引擎会按「此刻」的时区规则重新计算显示，导致同一 Date 实例在不同时刻 toString() 结果不同。更危险的是：它根本不记录原始时区上下文。
实操建议：
- 永远别用
new Date().getTimezoneOffset()推算某历史/未来时刻的偏移——比如你想知道“2024-10-27T02:30:00 在柏林是否处于夏令时”，Date给不出答案 - 若必须从字符串解析带时区的时间，优先走
Temporal.Instant.from('2024-10-27T02:30:00+02:00')，它不依赖宿主环境，也不固化偏移 - 旧代码桥接时，可用
Temporal.Instant.from(date).toZonedDateTimeISO({timeZone: 'Europe/Berlin'})补救，但别反过来把ZonedDateTime转回Date—— 那等于主动丢掉时区语义
用 Temporal.PlainDateTime 处理“无时区日历时间”（如营业时间、生日）
传统做法用 new Date('2024-06-15T10:00') 表示门店上午 10 点开门，结果部署到纽约服务器就自动变成 UTC-4 时间，再转成本地显示可能错成凌晨 1 点——因为 Date 强制绑定运行时本地时区。
实操建议：
- 明确业务语义：如果只是“每年 6 月 15 日上午 10 点”，不涉及真实世界时刻，就用
Temporal.PlainDateTime.from('2024-06-15T10:00') - 它不参与任何时区计算，也不会被
add({days: 1})拉进 DST 边界陷阱；要转成真实时刻，再显式 .toZonedDateTimeISO({timeZone: 'Asia/Shanghai'}) - 注意：
PlainDateTime不接受时区偏移字符串，Temporal.PlainDateTime.from('2024-06-15T10:00+08:00')会报错——这正是设计意图：逼你承认“这个时间到底有没有时区”
用 Temporal.ZonedDateTime 进行跨时区事件建模（如航班、会议）
航班到达时间不是“UTC 时间加 775 分钟”，而是“香港时间出发后飞行 775 分钟，再映射到洛杉矶时区的本地钟表”。Date 只能做线性毫秒加减，而 ZonedDateTime 把 IANA 时区数据库查表逻辑封装进 .add() 和 .withTimeZone()，自动处理 DST 切换日的“跳过”或“重复”小时。
实操建议：
- 创建时必须带完整时区 ID：
Temporal.ZonedDateTime.from('2020-03-08T11:55:00+08:00[Asia/Hong_Kong]')，不能只写+08:00—— 后者是静态偏移，无法响应未来政策调整（比如某年取消夏令时） - 跨时区加减，优先转
Instant再转回：zdt.toInstant().add({days: 1}).toZonedDateTimeISO({timeZone: 'America/Los_Angeles'})，避免zdt.add({days: 1})因 DST 导致“少一小时”或“多一小时” - 遇到夏令时边界（如柏林 2024-10-27 凌晨 2:00），
ZonedDateTime会查数据库确认该时刻是否合法；非法输入（如 2:30 在“跳过”区间）直接抛RangeError，不静默修正
Temporal.Instant 是唯一可安全用于计算的类型
所有时间差、定时器、数据排序、缓存过期判断，都该基于 Temporal.Instant。它是纳秒精度、线性、无闰秒、不依赖日历的绝对时间点。一旦混入 ZonedDateTime 做加减，你就回到了“某地早上 9 点加一天=？”，答案取决于那天有没有 DST 切换。
实操建议：
- 服务端存储、数据库字段、API 传输时间戳，统一用
Instant.toString()（即 ISO 8601 扩展格式，含 Z） - 前端展示前才转成
ZonedDateTime：instant.toZonedDateTimeISO({timeZone: Intl.DateTimeFormat().resolvedOptions().timeZone}) -
Temporal.Now.instant()是可信的起点；但Temporal.Now.zonedDateTimeISO()只适合做 UI 默认值，千万别拿它算“30 分钟后提醒”——用户改系统时区会导致提醒漂移
最易被忽略的一点：Temporal 不提供“自动修复模糊输入”的能力。它要求你从第一行代码就声明清楚“这是日历时间？瞬时点？还是带时区的本地时刻？”。这种强制显式，不是限制，而是把原本藏在 Date 里的隐式假设全部翻到台面上来——错，就错得明白；对，才对得可靠。
