Temporal.TimeZone 是时间调度中枢而非自动转换工具，必须显式调用 withTimeZone() 查 IANA 数据库映射；构造 ZonedDateTime 需先建 PlainDateTime 再绑定 IANA 时区名，禁用字符串拼接；渲染须用 withTimeZone().toString()，禁用 toLocaleString()；跨时区比对须归一为 Instant。
Temporal.TimeZone 不是“转换工具”，而是多时区会议系统的时间调度中枢——它不自动转换，只在你明确调用 withTimeZone() 时，依据 IANA 数据库查表映射；用错方式，会议时间会提前或延后一小时，且毫无提示。
构造 ZonedDateTime 必须带方括号 IANA 时区名，不能只传偏移
会议开始时间来自用户输入（如“2026-05-15 14:00”）+ 时区选择（如“Europe/Berlin”），必须走两步：先建 PlainDateTime，再显式绑定时区生成 ZonedDateTime。直接拼字符串如 '2026-05-15T14:00+02:00' 传给 ZonedDateTime.from() 会 TypeError 或静默降级为 PlainDateTime，彻底丢失夏令时识别能力。
-
Temporal.PlainDateTime.from('2026-05-15T14:00')→ 只校验日历合法性（比如拒绝 2 月 30 日） -
plain.toZonedDateTimeISO('Europe/Berlin')→ 查 IANA 库确认：2026 年 5 月柏林处于夏令时（UTC+2），返回2026-05-15T14:00:00+02:00[Europe/Berlin] - 若用户选的是
America/New_York，同一天同一本地时间对应 UTC−4，toZonedDateTimeISO()自动返回+04:00偏移
前端渲染会议时间必须用 withTimeZone()，禁用 toLocaleString()
用户看到的“北京时间 20:00”“纽约时间 08:00”必须由 zdt.withTimeZone(timeZoneId).toString() 生成。用 toLocaleString({ timeZone: 'Asia/Shanghai' }) 在部分浏览器或系统语言设置下会忽略 timeZone 参数，退化为本地时区显示。
- 正确：会议实例
zdt（原始为柏林时间）→zdt.withTimeZone('Asia/Shanghai').toString()输出2026-05-15T20:00:00+08:00[Asia/Shanghai] - 错误：用
zdt.toLocaleString({ timeZone: 'Asia/Shanghai' })，Chrome 可能输出"5/15/2026, 8:00 PM"，Safari 可能输出中文格式，且不保证时区生效 - 特别注意：夏令时间隙（如 2026-03-09 凌晨 2:15 在纽约）调用
withTimeZone()仍会抛RangeError，需前置拦截并提示用户修正时间
跨时区比对与倒计时必须归一为 Instant
两个不同 ZonedDateTime 实例即使指向同一物理时刻，.equals() 也返回 false；而会议是否“已开始”、倒计时还剩多少毫秒，必须基于绝对时间轴判断。
- 判断会议是否过期：
zdt.getEpochNanoseconds() - 服务端下发倒计时起点：
zdt.toInstant().getEpochNanoseconds()（纳秒级 UTC 时间戳），前端用Temporal.Instant.fromEpochNanoseconds(ns)恢复，再按用户时区转回显示 - 避免在
ZonedDateTime上直接.add({ minutes: 30 })做提醒逻辑——它按本地日历推进，DST 边界可能导致实际间隔不是 30 分钟（例如跨夏令时切换日，加 1 小时可能等于 59 或 61 分钟）
真正容易被忽略的点是：所有用户输入的“本地时间”都只是日历意图，它本身没有物理意义；只有绑定真实地理时区（Asia/Tokyo 而非 +09:00）并经 Temporal.TimeZone 查表确认后，才成为可调度、可比对、可存储的真实事件时刻。
