temporal 是专为解决夏令时边界问题重新设计的时间模型，通过 plaindatetime 校验日历合法性、zoneddatetime 显式处理时区歧义，并强制分离解析、比较、显示三阶段时区职责。
Temporal 不是 Date 的补丁，它是专为解决夏令时（DST）边界问题而重新设计的时间模型。如果你还在用 new Date() 解析用户输入的本地时间、依赖 toLocaleString() 做日志或序列化、或者靠 getTimezoneOffset() 手动加减小时——那夏令时切换日的偏差不是“会不会出现”，而是“哪天爆出来”。
为什么 new Date('2024-03-10T02:30') 在北美会静默错位
这是最典型的“跳跃时间”（gap）场景：北美东部时间在 3 月第二个周日从 EST（UTC−5）切到 EDT（UTC−4），凌晨 2:00 直接跳到 3:00。字符串 '2024-03-10T02:30' 对应的时刻根本不存在，但 Date 会自动回滚或前推（行为因引擎而异），返回一个看似合理却完全错误的 Date 实例，且不抛错、不警告。
-
Temporal.PlainDateTime.from('2024-03-10T02:30')会直接抛RangeError，因为校验日历合法性时发现该时间在标准日历中无效（非时区问题，纯结构非法） - 若你传的是模糊但合法的时间（如
'2024-11-03T01:30'，夏令时结束日的“重叠时间”），PlainDateTime仍能通过——它只管日历，不管时区规则 - 真正需要判断 DST 归属的环节，必须交由
Temporal.ZonedDateTime显式处理，靠构造器参数控制歧义策略
ZonedDateTime.from() 必须带 IANA 时区名，不能只传偏移
传 '2024-11-03T01:30-05:00' 这类带固定偏移的字符串，ZonedDateTime.from() 会忽略夏令时逻辑，把它当作无规则的 UTC−5 固定偏移来用——这在跨年查询历史事件时必然出错。真实业务中，America/Chicago 在 2024 年 11 月 3 日 01:30 是 CST（UTC−6），不是 CDT（UTC−5）；但如果你硬塞 -05:00，就等于主动放弃 tzdata 数据库的动态查表能力。
- 正确写法：
Temporal.ZonedDateTime.from('2024-11-03T01:30[America/Chicago]')—— 方括号内必须是完整 IANA 名 - 遇到重叠时间（如 01:30 出现两次），默认策略
disambiguation: 'compatible'会取后一次（即标准时间 CST），但你可以显式指定：{ disambiguation: 'earlier' }或{ disambiguation: 'later' } - 传入
'2024-03-10T02:30[America/Chicago]'会直接报RangeError: Invalid time，因为该时刻在该时区下不存在
接收用户输入时，PlainDateTime + withTimeZone() 是唯一安全路径
前端表单提交的 “2024-10-27 02:30” 是纯日历时间，不含任何时区语义。如果直接喂给 ZonedDateTime.from()，它会尝试按当前系统时区解析，又掉回 Date 的坑里。必须分两步：先剥离时区上下文做结构校验，再绑定地理时区做语义解释。
- 第一步：
const plain = Temporal.PlainDateTime.from('2024-10-27T02:30')—— 确保字符串格式合法、日期存在（如排除 2 月 30 日） - 第二步：
const zdt = plain.withTimeZone('Europe/Berlin')—— 此时才查 tzdata，确认该日该时在柏林是夏令时（CEST, UTC+2）还是标准时间（CET, UTC+1） - 不要用
plain.toZonedDateTimeISO()，它隐式使用'local'时区，不可控 - 服务端收到用户选择的时区（如
'Asia/Tokyo'），必须和PlainDateTime配对使用，不能拼接字符串再解析
比较、存储、显示三阶段必须严格分离时区职责
同一个时间点，在不同时区下 .toString() 结果不同，但 .getEpochNanoseconds() 必须一致。混淆这三件事，是跨时区系统最常崩的点。
- 比较两个时间？必须都转成
ZonedDateTime，然后用.getEpochNanoseconds()比数值，别用.equals()—— 后者会因时区名不同返回false，哪怕指向同一瞬时 - 数据库存什么？只存
zdt.getEpochNanoseconds()（或等效 UTC 时间戳）+ 用户原始时区字符串（如'America/Los_Angeles'），绝不要存偏移量（如'+07:00'） - 前端显示本地时间？用
zdt.withTimeZone('local').toString()，而不是zdt.toLocaleString()—— 前者可控、可测试；后者受系统语言、数字格式、甚至浏览器 bug 影响
真正难的不是写对一行 ZonedDateTime.from()，而是让整个团队理解：时间不是“某个字符串+某个偏移”，而是“日历时间 + 地理时区 + 显式歧义策略”的三元组。一旦有人偷偷把 toISOString() 当“标准时间”用，或者在日志里混用 toLocaleString() 和 toJSON()，整条链路就回到靠经验踩坑的老路。
