必须用 Temporal.ZonedDateTime 替代 Date，严格使用 IANA 时区名（如 [Europe/Berlin]）构造，所有时间运算须基于 Instant 或显式指定 disambiguation 策略，否则夏令时切换日将导致排课错位一小时。
直接说结论：用 Temporal.ZonedDateTime 替代所有 Date 实例，且必须用 IANA 时区名（如 [Europe/Berlin]）构造，不能只传 +02:00；所有“加一天”“比对时间”操作都必须基于 Instant 或显式声明 disambiguation 策略——否则排课系统会在夏令时切换日集体错位一小时。
为什么排课系统在 3 月/10 月凌晨总出 bug
传统方案用 new Date('2026-03-30T02:30') 解析柏林课表时间，但那天凌晨 2:00–2:59 在 Europe/Berlin 不存在（钟从 02:00 直跳 03:00）。Date 会静默转成 03:30，且不报错；更糟的是，它内部只存毫秒数，后续调用 getHours() 返回的仍是“本地浏览器时区”的值，和原始课表完全脱钩。
Temporal.ZonedDateTime.from() 遇到这种间隙直接抛 RangeError: invalid time，强制你在代码里处理——比如提示用户改选 01:30 或 03:30，而不是让错误潜伏到上课当天。
- 错误现象：同一门课在柏林显示为 02:30，在纽约却显示为 21:30（应为 20:30），差一小时
- 根本原因：
Date把字符串先按本地时区解析，再转 UTC，中间丢失原始时区上下文 - 关键区别：
Temporal.ZonedDateTime绑定的是动态时区规则（查 IANA 数据库），不是静态偏移
创建课表时间必须带方括号时区名
排课系统录入“柏林时间 2026-10-26 09:00 开课”，不能写成 '2026-10-26T09:00:00+02:00'——这只会被当成固定偏移，无法表达“10 月 26 日柏林已切回标准时间（UTC+1）”的事实。
正确写法是：
const classTime = Temporal.ZonedDateTime.from('2026-10-26T09:00:00+01:00[Europe/Berlin]');
注意：+01:00 是查表后得到的当前偏移，[Europe/Berlin] 才是决定未来所有计算的动态时区标识。漏掉方括号会直接抛 TypeError。
- ✅ 支持历史/未来推演：对 1986 年柏林课表，自动用 +02:00（当时实行夏令时）
- ✅ 夏令时重叠时刻可选策略：如
2026-10-26T02:30出现两次，用disambiguation: 'earlier'明确取第一次 - ❌ 传
'2026-10-26T09:00:00[Europe/Berlin]'会失败——必须含偏移或用PlainDateTime.toZonedDateTimeISO()
跨时区排课对比与提醒必须用 Instant 中转
学生在北京、教师在柏林、助教在纽约，三方看到的“同一节课开始时间”必须严格对应同一物理时刻。若直接用 zdt1.equals(zdt2)，即使指向同一 UTC 时间，也会因时区字段不同返回 false。
正确做法是统一转成 Temporal.Instant 比较：
const beijingClass = Temporal.ZonedDateTime.from('2026-04-27T14:00:00+08:00[Asia/Shanghai]');
const berlinClass = Temporal.ZonedDateTime.from('2026-04-27T08:00:00+02:00[Europe/Berlin]');
console.log(beijingClass.getEpochNanoseconds() === berlinClass.getEpochNanoseconds()); // true
- ⏰ 提醒逻辑：用
Instant.now().until(classTime.toInstant(), { largestUnit: 'minutes' })计算倒计时，避免zdt.add({hours: 1})在夏令时边界多算/少算一小时 - ? 显示逻辑：前端按用户本地时区调用
classTime.withTimeZone('local').toString()，而非toLocaleString() - ⚠️ 切忌：不要对
ZonedDateTime直接做add({days: 1})来生成下周课表——它按日历语义推进，可能跨过 DST 切换点；应先转toInstant()再加
表单输入与数据库存储的分工要清晰
用户在网页表单填“上课时间：09:00”，这个 09:00 是纯日历意义，不绑定任何时区。用 Date 存会强制绑定浏览器时区，导致部署在不同时区服务器上行为不一致。
正确分工：
- 表单提交 → 用
Temporal.PlainDateTime.from({ hour: 9, minute: 0 })解析，存为"09:00"字符串 - 关联教室时区 → 查数据库得
room.timeZone = 'Europe/Berlin'，再调用plain.withTimeZone('Europe/Berlin') - API 返回给前端 → 用
zdt.toString()（含完整时区信息），而非toISOString()
最易被忽略的一点：夏令时切换日的“重复时间”（如 2026-10-26T02:30）在数据库里必须存明确策略（disambiguation: 'later'），否则同一字符串在不同环境解析结果可能不同——这不是 bug，是 Temporal 强制你把模糊性显式暴露出来。
