Temporal提案要求彻底替换而非升级Date，因其内部仅存毫秒数且固化时区偏移，导致解析显示不一致；应优先用PlainDateTime处理无时区时间、ZonedDateTime处理真实事件、Instant处理精确时间点，严格区分三类时间语义。
Temporal 提案能彻底绕过 Date 的时区偏移陷阱，但前提是必须放弃所有 Date 实例操作——不是“升级”，而是“替换”。
为什么 Date.prototype.getTimezoneOffset() 总返回错的值？
它返回的是「本地时区相对于 UTC 的分钟偏移」，且这个值在构造时就固化了，后续调用 toString() 或 toLocaleString() 时却可能用另一个时区规则（比如夏令时切换后），导致时间解析和显示不一致。更糟的是，Date 内部只存毫秒数，不记录原始时区信息，一转换就丢上下文。
实操建议：
- 永远别用
new Date().getTimezoneOffset()去推算某个具体时刻的偏移——它只反映“此刻浏览器默认时区”的当前偏移，不是动态的 - 避免用
Date解析带时区的字符串（如"2023-10-05T14:30:00+09:00"），JS 引擎会强制转成本地时区再存毫秒，原始偏移丢失 - 如果必须兼容旧代码，至少把输入字符串先用
Temporal.Instant.from()解析，再转成Date（仅作临时桥接）
用 Temporal.PlainDateTime 替代“无时区时间”场景
很多业务要处理“2024-06-15 10:00”这种不含时区的本地时间（比如门店营业时间、生日），Date 强制绑定本地时区，导致跨地区部署时行为漂移。Temporal.PlainDateTime 明确表示“纯日历+钟表时间”，不参与任何时区计算。
示例对比：
const legacy = new Date('2024-06-15T10:00'); // 在东八区是 UTC+8，在西五区是 UTC-5，同一字符串含义不同
const temporal = Temporal.PlainDateTime.from('2024-06-15T10:00'); // 永远就是“6月15日10点”，不隐含时区
实操建议：
- 表单录入的“日期+时间”字段，优先用
Temporal.PlainDateTime.from({ year, month, day, hour, minute })构造 - 需要转成带时区的时间点时，显式调用
.withTimeZone('Asia/Shanghai')，而不是靠Date自动猜 - 数据库存这类值，建议用
PlainDateTime.toString()（如"2024-06-15T10:00"），比存Date.toISOString()更语义清晰
用 Temporal.ZonedDateTime 处理真实世界的时间事件
会议、航班、服务器日志这些必须绑定具体时区的场景，Date 只能靠字符串后缀（如 "2024-06-15T10:00:00+08:00"）硬编码偏移，但夏令时会让 +08:00 变成 +09:00，而 Date 不知道 IANA 时区规则，无法自动修正。ZonedDateTime 把时区名（如 "Europe/Berlin"）和时刻绑定，查系统时区数据库做动态偏移计算。
实操建议：
- 用户选择时区后，立刻用
Temporal.ZonedDateTime.from({ plainDateTime, timeZone: 'America/New_York' })创建实例，不要先造Date - 比较两个事件是否同时发生，直接用
zdt1.equals(zdt2)，不用手动换算毫秒——它已按 IANA 规则对齐到同一时刻 - 导出给后端，用
zdt.toString()（如"2024-06-15T10:00:00-04:00[America/New_York]"），保留完整上下文
真正难的不是 API 调用，而是把“时间”从 Date 的隐式时区模型里解耦出来：哪些是日历时间（PlainDateTime），哪些是物理时刻（Instant），哪些是带政策含义的时间点（ZonedDateTime）。一旦混用类型，比如把 PlainDateTime 直接传给需要 Instant 的函数，错误不会立刻报，而是在夏令时切换那天凌晨三点突然出现。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
