Temporal.TimeZone 是全球化时间处理中枢，需用 IANA 标识符（如 'Asia/Tokyo'）显式声明，配合 PlainDateTime 实现跨时区安全转换，避免静态偏移；withTimeZone() 自动处理夏令时，边界异常需捕获并指定消歧策略。
Temporal.TimeZone 不是辅助工具，而是全球化时间处理的中枢。它不存储时间，只负责把某个时刻映射到具体时区的本地表达——比如“2026-05-06T14:10Z”在东京是几点、在纽约又是几点，全靠它实时查表决定。
用 TimeZone.from() 显式声明时区上下文
别依赖浏览器默认时区，也别靠字符串后缀猜偏移。所有跨时区操作起点必须是明确的 IANA 时区标识符：
- ✅ 正确：const tz = Temporal.TimeZone.from('Asia/Tokyo')；后续可安全用于 toZonedDateTimeISO() 或 withTimeZone()
- ❌ 错误：直接传 'UTC+9' 或 '+09:00' —— 这是静态偏移，无法响应夏令时或历史规则变更
- ⚠️ 注意：'Etc/GMT+9' 表示 UTC−9（IANA 命名反直觉），应优先用 'Asia/Tokyo' 这类地理标识
把 PlainDateTime 和 TimeZone 组合，解耦“日历”与“时区”
门店营业时间、生日、会议预约等场景，本质是“某地某日某时”，不是“某个 UTC 时间点”。这时 PlainDateTime + TimeZone 是黄金组合：
- const plain = Temporal.PlainDateTime.from('2026-05-10T09:00')；// 纯日历时间，无歧义
- const tokyoTime = plain.toZonedDateTimeISO(Temporal.TimeZone.from('Asia/Tokyo'))；// 自动匹配当日偏移（2026年东京仍用 JST +09:00）
- const newYorkTime = tokyoTime.withTimeZone('America/New_York')；// 同一时刻，换算为纽约本地时间
用 withTimeZone() 做瞬时转换，而非手动加减偏移
显示给用户看的时间，必须走 withTimeZone()，而不是 getHours() + offset：
- ❌ 错误：zdt.hour + (zdt.timeZone.getOffsetNanosecondsFor(zdt.epochNanoseconds) / 3.6e12) —— 手动算易错，且忽略 DST 边界
- ✅ 正确：zdt.withTimeZone('Europe/Paris').toString()；// 内部查表，自动识别 2026 年 3 月最后一个周日已切夏令时（CEST +02:00）
- ? 提示：前端渲染本地时间，推荐 zdt.withTimeZone('local').toString()，比 toLocaleString() 更稳定（不受系统语言/格式设置干扰）
捕获并处理时区边界异常
夏令时切换日会出现“不存在的时间”（如 2:00–2:59 跳过）或“重复的时间”（如 1:00–1:59 出现两次）。TimeZone 会配合 ZonedDateTime 主动暴露问题：
- 尝试构造 '2026-03-08T02:30[America/New_York]' 会抛 RangeError；这不是 bug，是提醒你需引导用户选择 1:30 或 3:30
- 对 '2026-11-01T01:30[America/New_York]'（重叠时刻），可显式指定 disambiguation: 'earlier' 或 'later'
- 业务关键路径建议包裹 try/catch，并提供 fallback 逻辑，比如自动选 earlier 时间段
