Temporal.TimeZone 是跨区域时间逻辑的调度中枢，通过 IANA 数据库精确映射 Instant 到本地时刻，支持夏令时、历史变更与政策弹性，禁止使用静态偏移；时区存储应为 IANA 名（如 Asia/Shanghai），显示须用 withTimeZone() 而非 toLocaleString()；跨时区比对必须归一为 Instant；边界异常（如 DST 间隙/重叠）需主动拦截并引导用户修正。
Temporal.TimeZone 不是辅助工具，而是跨区域时间逻辑的调度中枢。它不存储时间，只负责把某个 Instant 映射成特定地理规则下的本地时刻——这个映射过程必须显式触发，不能隐含在构造或格式化中。
用 TimeZone.from() 绑定真实地理规则，而非静态偏移
传 +08:00 或 GMT+8 会丢失所有夏令时、历史变更和政策弹性；而 TimeZone.from('Asia/Shanghai') 会查内置 IANA 数据库，确认中国自 1992 年起已取消夏令时，始终返回 +08:00；TimeZone.from('Europe/Paris') 则自动识别每年 3 月最后一个周日切至 +01:00，10 月最后一个周日切回 +00:00。
- 后端接收用户提交的“2026-04-25T09:15”，应先转为 PlainDateTime，再结合用户选择的时区 ID 调用
.toZonedDateTimeISO(timeZone) - 禁止拼接字符串如
'2026-04-25T09:15+08:00'后传给 ZonedDateTime.from()，这会因缺方括号时区名直接 TypeError - 数据库存时区信息，应存 IANA 名（如
Asia/Tokyo），而不是偏移值，否则无法支撑未来政策调整
显示校准时必须用 withTimeZone()，禁用 toLocaleString()
toLocaleString() 受浏览器语言、时区、数字格式等系统设置干扰，同一段代码在不同设备上可能输出 “4/25/2026, 9:15 AM” 或 “2026/04/25 09:15”；而 zdt.withTimeZone('local').toString() 是确定性操作：它以当前系统时区为显示目标，但底层仍走 IANA 规则查表，确保 2026-03-09 凌晨 2:15 在纽约设备上显示为无效提示，而非静默跳到 3:15。
- 前端会议列表渲染，统一用
zdt.withTimeZone(userPrefTimeZone).toString()，不依赖用户系统设置 - 服务端生成邮件模板中的时间，用
zdt.withTimeZone('Asia/Shanghai').toString()强制固定显示逻辑 - 避免
zdt.toLocaleString({ timeZone: 'Asia/Shanghai' })，该写法在部分环境可能忽略 timeZone 选项
跨区域比对与调度必须归一为 Instant
两个不同时区的 ZonedDateTime 即便指向同一物理时刻，.equals() 也返回 false；而 .getEpochNanoseconds() 提取的是纳秒级 UTC 基准，可安全用于排序、去重、倒计时触发判断。
- 全球考勤打卡时间入库前，立刻调用
.toInstant()，存储为 BIGINT 或 ISO 字符串（如"2026-04-25T01:15:00.000000000Z"） - 计算“距离下次同步还有多久”，先转 Instant，用
.add({ hours: 24 })，再按需转回各地区 ZonedDateTime 显示 - 禁止对 ZonedDateTime 直接做
add({ days: 1 })后跨时区比较，夏令时切换日会导致结果漂移一小时
主动拦截边界异常，把错误变成交互机会
Temporal 不掩盖问题：遇到夏令时间隙（如 "2026-03-09T02:15[America/New_York]"）直接抛 RangeError: invalid time；遇到重叠（如 "2026-11-02T01:30[America/New_York]"）默认拒绝，除非显式指定 disambiguation: 'earlier' 或 'later'。
- 表单提交失败时，前端可弹出选项：“您是指夏令时结束前的 1:30，还是结束后的 1:30？”
- API 返回 400 错误时附带字段
errorType: "invalid-dst-time"和建议修正时间，供客户端引导用户 - 后台批处理脚本捕获此类错误后记录原始字符串与上下文，不静默跳过或硬编码补偿
