Temporal.ZonedDateTime 算错课时是因为硬加1小时忽略夏令时边界时刻不存在或重复，导致静默跳转；应显式构造、检查offset变化、避免2:00–3:00区间运算。
夏令时切换当天 Temporal.ZonedDateTime 为什么算错课时？
因为 Temporal.ZonedDateTime 默认使用系统时区数据库（IANA tzdb）的规则，但很多排课系统直接用 withPlainTime 或 add 操作“硬加1小时”，忽略了夏令时边界时刻可能不存在（如春调跳过 2:00–2:59）或重复（如秋调回拨出现两个 2:00）。这类操作会静默跳到下一个有效时间点，导致课程提前/延后一小时——不是 bug，是设计行为。
实操建议：
- 永远用
with({hour, minute})+timeZone显式构造，而非基于已有实例做add({hours: 1}) - 检查夏令时切换日：用
timeZone.getOffsetNanosecondsFor(plainDateTime)对比前后两天，确认 offset 是否变化 - 避免在
2:00–3:00区间内做时间运算；若必须，先用timeZone.getPossibleInstantsFor(plainDateTime)拿到所有候选 Instant，再选最符合业务逻辑的那个
跨多时区排课时，Temporal.ZonedDateTime 和 Temporal.PlainDateTime 怎么选？
用 PlainDateTime 表示“本地课表时间”（比如“每周三 14:00 上课”），用 ZonedDateTime 表示“某地某刻的真实发生时刻”。两者不能混用比较或计算——PlainDateTime 没有时区语义，ZonedDateTime 含偏移和规则。
常见错误现象：把教师所在东京的 ZonedDateTime 和学生所在洛杉矶的 PlainDateTime 直接相减，得到错误的“差8小时”结论（实际可能是7或8小时，取决于是否同时处于夏令时）。
实操建议：
- 课表元数据存
PlainDateTime+timeZone字符串（如"Asia/Tokyo"），不存ZonedDateTime - 生成具体上课时刻时，用
PlainDateTime.withTimeZone(timeZone)构造ZonedDateTime，再转Instant做统一比较 - 学生端显示时，用
zdt.withTimeZone(userTimeZone)转换，而不是手动加减固定小时数
Temporal.ZonedDateTime.from() 解析字符串时容易漏掉哪些隐含规则？
它默认使用当前 IANA 数据库版本解析，但不同 Node.js 版本、浏览器、甚至同一环境里不同 Temporal 实例的 tzdb 版本可能不一致。更危险的是：当输入字符串带缩写（如 "2024-11-03T02:30:00 PST"），from() 会忽略缩写含义，只按 IANA 规则推断 offset——PST 在 11 月确实是 -8，但如果用户误输成 "PDT"，也不会报错，而是强行映射到当前规则下的最近匹配。
实操建议：
- 禁止在生产环境用带时区缩写的字符串初始化；统一用 IANA 时区名 + ISO 格式（如
"2024-11-03T02:30:00-08:00[America/Los_Angeles]"） - 校验输入时，用
Temporal.TimeZone.from(timeZoneString).getOffsetNanosecondsFor(instant)反查 offset，确保与字符串中显式写的 offset 一致 - CI 中加入 tzdb 版本检查：运行
Temporal.now.timeZone().id并比对预期值，防止部署环境 tzdb 落后
学生投诉“明明设置了 9:00 上课，却收到 10:00 的提醒”，问题出在哪？
大概率是前端用了 toLocaleTimeString() 渲染 ZonedDateTime，而该方法依赖宿主环境的 Intl API 实现——某些旧版 Safari 或 Electron 内核会缓存时区规则，不随系统更新自动刷新，导致夏令时切换后仍沿用旧 offset。
性能影响：每次调用 toLocaleTimeString() 都触发 ICU 格式化，比 zdt.toString() 慢 3–5 倍，且不可控。
实操建议：
- 前端显示一律用
zdt.toLocaleString('en-US', { timeZoneName: 'short' })，并确保timeZone参数传入明确的 IANA 名（不要依赖undefined） - 服务端下发提醒时间时，直接提供
Instant+ 用户时区名，由前端构造ZonedDateTime，避免服务端做格式化 - 在夏令时切换前 72 小时，对所有活跃用户的
PlainDateTime+timeZone组合做一次withTimeZone()验证，记录 offset 变化预警
真正棘手的不是夏令时本身，而是系统里混着 Plain、Zoned、Instant 三种时间模型，又没在边界处做类型断言和规则校验。一个 getPossibleInstantsFor 调用，往往比十个 try-catch 更早拦住问题。
