題目與背景
一個全球預約系統接收「紐約時間 2026-11-01 01:30」的輸入，並在參與者所在時區顯示和提醒。請使用 JavaScript Temporal 設計從輸入、時區解析、持久化到顯示的流程，處理夏令時間重複或不存在的本地時間。不要用一個裸字串或 Date 物件混淆日期、時間和時區語意。
面試官考察什麼
重點是區分 Temporal.Instant、Temporal.ZonedDateTime、Temporal.PlainDateTime 和 Temporal.PlainDate，理解 IANA 時區規則、DST 歧義、精度與序列化。優秀答案會說明業務曆法日期不能直接轉成 UTC 瞬時點，以及如何固定曆法系統。
先問清楚的澄清問題
輸入語意
確認使用者輸入是「某時區的牆上時間」還是已確定的瞬時點，時區來自事件、組織還是瀏覽器。缺少時區就不能可靠解釋本地時間。
DST 歧義策略
確認不存在或重複時間時是拒絕、選擇較早、選擇較晚還是讓使用者確認。預設策略必須寫入產品契約，不能由執行時偶然決定。
持久化需求
確認提醒是否代表一次絕對瞬時事件，還是每年在當地日期重複。一次性預約與生日類規則需要不同的 Temporal 型別。
30 秒回答框架
「先把使用者輸入保留為 PlainDateTime 與明確的 IANA 時區，再按產品策略轉換成 ZonedDateTime 和 Instant。一次性提醒持久化 Instant，顯示時用參與者時區重新轉換；重複曆法事件持久化日期、時間、時區和曆法規則。對 DST 缺失或重複時間顯式拒絕或選擇策略，並保存原始語意，避免使用 Date 的隱式本地時區解析。」
深入解答步驟
第一步：選擇正確型別
PlainDate 表示沒有時區的曆法日期，PlainDateTime 表示沒有時區的牆上時間，ZonedDateTime 綁定 IANA 時區，Instant 表示時間線上的單一點。先判斷業務語意再選型別。
第二步：解析並綁定時區
解析使用者輸入得到 PlainDateTime，從可信設定取得時區識別，再組合成 ZonedDateTime。禁止把瀏覽器預設時區或伺服器時區偷偷當作事件時區。
第三步：處理 DST 變化
春季跳時會產生不存在的本地時間，秋季回撥會產生重複的本地時間。使用明確的 disambiguation 策略，例如拒絕並讓使用者重選，或在需求允許時選擇 earlier/later；把選擇記錄在預約資料中。
第四步：轉換為提醒瞬時點
一次性預約從 ZonedDateTime 取得 Instant 並以標準化字串保存。調度器按 Instant 觸發，展示層再根據查看者時區轉換，而不是重新解釋原始牆上時間。
第五步：保存重複事件語意
每年某地 09:00 的事件不能只保存一個 UTC 偏移，因為 DST 會改變偏移。保存 PlainDate、PlainTime、IANA 時區和曆法系統，每次發生時重新解析成當年的 ZonedDateTime。
第六步：定義精度與曆法
明確是否需要毫秒、微秒或奈秒精度，序列化時不要截斷導致排序錯誤。跨曆法業務要保存 calendar 識別，不能把使用者曆法日期直接當成 ISO 公曆日期。
第七步：測試邊界
覆蓋 DST 跳時和回撥、跨年、閏日、時區資料庫更新、不同語言環境和序列化往返。測試應斷言瞬時點、當地展示和重複規則分別正確，而不只比較字串。
高品質示例回答
我會將輸入解析為 PlainDateTime，要求事件攜帶 IANA 時區，再按明確的 DST 歧義策略組合成 ZonedDateTime。一次性提醒持久化 Instant，展示時按查看者時區轉換；重複事件持久化當地日期、時間、時區和曆法規則，每次生成新的瞬時點。測試覆蓋缺失/重複時間、閏日、時區庫更新和序列化精度，避免 Date 的隱式時區行為。
常見錯誤
- 錯誤： 把
PlainDateTime直接當 UTC。→ 原因： 它沒有時區語意。→ 改進： 先綁定明確的 IANA 時區。 - 錯誤： 每年重複事件只保存 UTC 偏移。→ 原因： DST 會改變當地偏移。→ 改進： 保存當地時間和時區規則。
- 錯誤： 忽略秋季回撥的重複時間。→ 原因： 一個牆上時間對應兩個瞬時點。→ 改進： 拒絕或顯式選擇 earlier/later。
- 錯誤： 只用字串比較驗證結果。→ 原因： 字串無法證明瞬時點和曆法語意。→ 改進： 分別斷言 Instant、ZonedDateTime 和重複規則。
追問與回答
追問 1：什麼時候應該持久化 Instant？
當事件代表時間線上的一次絕對發生，例如傳送提醒或記錄付款。查看者時區只影響展示，不應改變該瞬時點。
追問 2：為什麼生日不能保存成 Instant？
生日表達的是當地曆法日期，通常不代表某個全球同時發生的瞬時點。保存日期、時區和曆法規則，發生時再計算 Instant。
追問 3：時區資料庫更新會影響已保存預約嗎？
會。未來本地時間的規則可能變化，因此保存原始時區和語意，並記錄規則版本或在重新計算時採用明確的業務策略。
追問 4：Temporal 能否自動決定 DST 歧義？
API 可以提供 disambiguation 選項，但產品仍需決定拒絕、取早、取晚或相容。不能把預設選項當成業務共識。