先了解的事
首爾剛過午夜時，紐約可能仍是前一天上午。同一瞬間可以有不同的當地日期，不要自行加一天修正。傳送行程時請同時提供日期與時間。
實際操作步驟
當地日期與時間 要輸入來源地的當地日期時間，不是目的地的。從 來源時區 與 目標時區 選擇提供的時區，再按 計算。這不是任意輸入 IANA 名稱的欄位，也不是固定時差的心算。
已驗證的範例
2026-01-15 00:30、Asia/Seoul→America/New_York 的實際英文結果為 Jan 14, 2026, 10:30 · America/New_York，日期是 14 日而非 15 日。獨立 Python ZoneInfo 也確認此瞬間。複製完整結果後，在行事曆再次檢查日期。
| 輸入 | 輸出 |
|---|---|
2026-01-15 00:30 · Asia/Seoul | 2026-01-14 10:30 · America/New_York |
2026-01-15 12:00 · America/New_York | 2026-01-15 17:00 · UTC |
2026-07-15 12:00 · America/New_York | 2026-07-15 16:00 · UTC |
檢查結果
America/New_York 的 2026-01-15 12:00→UTC 為 17:00；2026-07-15 12:00→UTC 為 16:00。兩個實測日期的季節性 UTC 偏移不同。不要把一月的時差直接用到七月，也別假設各國同一天調時。瀏覽器的時區資料與未來規則變更也會影響結果。
發生問題時
紐約的 2026-03-08 02:30 不存在，2026-11-01 01:30 則出現兩次。工具拒絕兩者而沒有猜測。向主辦者確認不含歧義的當地時間，或使用已確認的 UTC 瞬間。其他結果異常時先重查來源日期、來源與目的時區。
常見問題
前一天的結果應改成今天嗎？
不要。先確認輸入，同一瞬間的當地日期本來就可能不同。
冬夏結果為何差一小時？
實測日期採用不同的季節性 UTC 偏移。
工具會替我選重複時刻嗎？
不會。模糊或不存在的當地時間會被拒絕。
限制
不是重複會議排程工具。只能用提供的時區與支援日期，過去及未來結果取決於瀏覽器時區資料。