Outlook 的時區下拉選單可讓你更改日曆顯示的當地時間，但它並不會自動為已排定的會議計算出另一個城市對應的正確時間 — 那個轉換必須另外進行，而且必須在日光節約時間（DST）下也保持正確，因為在大多數地區，時區偏移會在一年中調整兩次，每次一個小時。像紐約 9:00 AM 這樣的時鐘時間，並未錨定在某一個固定的 UTC 瞬間：在 1 月，它落在 Eastern Standard Time（UTC−5）之下，對應到 14:00 UTC；而同一個時鐘時間在 7 月則落在 Eastern Daylight Time（UTC−4）之下，對應到 13:00 UTC。一個假設紐約永遠是 UTC−5 的天真偏移對照表，在每年夏天都會整整差一個小時，而且會悄悄地把所有跨越 DST 界線所排定的會議都算錯。可靠的做法是，先根據該日期實際的 IANA 規則，將來源時鐘時間解析為一個真實的 UTC 瞬間，再為該精確瞬間重新推導出每個目標時區的偏移。Time Zone Converter 會在您的瀏覽器中使用標準的 Intl 日期引擎完成這個兩步驟的解析，並回傳每個目標時區的當地時間、日期、星期幾以及當下的 UTC 偏移，讓 Outlook 會議在送出前能被驗證。
為什麼 Outlook 的時區設定本身並不足夠
Microsoft Outlook 的日曆本身有時區控制選項，在傳統 Outlook 中通常位於 File → Options → Calendar → Time Zones，在新版 Outlook 中則位於 View Settings → Calendar → Time Zones。該設定會改變你的螢幕上如何呈現收到的和送出的事件。它並不會幫你把會議時間轉換成另一位參與者的當地時鐘；Outlook 將每一筆約會都儲存為一個 UTC 瞬間，只有顯示的這一層會反映目前作用中的時區。因此，當柏林的人寄給你一個 14:00 的邀請時，你在郵件內文中或當下自己日曆中實際看到的內容，取決於 Outlook 目前被設定為以哪個時區來呈現，而不是會議當初是在哪個時區所建立。
這是最容易造成混淆的部分。Outlook 可以顯示一個在你的時區以「15:00」開始的會議，而同一個 UTC 瞬間在別人的早晨卻是 09:00，而且它不會自動跳出任何提示，告訴你日期已經跨日，或是 DST 已把其中一個偏移推了一個小時。當你需要確認你所提出的「我的時間星期二 10:00」這個時段，在同一天確實落在東京、加爾各答和洛杉磯的上班時間內，唯一安全的方法就是根據會議的實際日期，逐一為每個時區進行換算，並把 DST 納入考量。
DST 問題：為何時鐘算術一年會失效兩次
時區計算中最棘手的部分是日光節約時間。像 12:00 這樣的時鐘讀數，並不對應一個固定的 UTC 瞬間；它只是一個標籤，唯有在知道你所查看的日期適用哪一條規則時，它才會被解析為真實的時間點。紐約在 1 月是 UTC−5（EST），在 7 月則是 UTC−4（EDT）；倫敦在 1 月是 UTC+0（GMT），在 7 月是 UTC+1（BST）；雪梨在南半球冬季是 UTC+10，在南半球夏季則是 UTC+11。這些調整在北半球和南半球發生的日期也不同，所以每年春秋各有幾週的時間裡，舉例來說，倫敦和雪梨之間的偏移，並非人們在學校記得的單純課本數字。
假設固定偏移的天真轉換器，會在一年的好幾個月中靜悄悄地產生差一個小時的錯誤時間，而且在每一次 DST 切換的兩端通常都會產生錯誤的結果。把一個時鐘時間從一個時區正確轉換到另一個時區，唯一正確的做法是：先根據來源時區在該日期的 IANA 規則，把來源的時鐘讀數轉成一個真實的 UTC 瞬間，然後再詢問目標時區在那一個精確瞬間它自己的 UTC 偏移是多少。以相反的順序來做 — 把「已知的」偏移相加 — 正是出錯的模式。Time Zone Converter 會先把來源的時鐘時間解析為 UTC，再於該瞬間重新推導出每個目標時區的偏移，這就是為什麼同一個 9:00 AM 的來源讀數，會依日期落在美國日光節約時間之內或之外，而被轉換為兩個不同的 UTC 瞬間。
如何正確轉換 Outlook 會議時間
在任何跨越 DST 界線或國際換日線的 Outlook 會議邀請送出之前，請將 Time Zone Converter 作為一道驗證步驟來使用。這些步驟對應到背後實際的計算方式。
- 輸入時間的方式，要與來源時區（Outlook 目前設定為顯示的那個時區）時鐘上所顯示的日期與時間完全一致，然後在 From zone 中選擇該時區。
- 從標籤中新增一個或多個目標時區，對應到你與會者所在的城市；如果你想進行範圍較廣的健全性檢查，也可以使用預設橫跨歐洲、亞洲等地的選項。
- 讀取每個目標的轉換後當地時間、日期、星期幾以及 UTC 偏移 — 這些是你在 Outlook 中確認時段之前，必須與與會者上班時間進行比對的數值。如果你正在確認一個尚未排定的會議，請點擊 Use current time，從你裝置上的當下時刻開始。
以一個排定在 7 月 15 日紐約 9:00 AM 的 Outlook 會議為例，轉換器會針對該日期解析 EST/EDT，並為你新增的每一個目標（包括東京、加爾各答和柏林）回傳正確的偏移。同一個時鐘讀數若落在 1 月 15 日，則會因為來源的 UTC 瞬間晚了一個小時，而回傳一組不同的偏移，轉換器會自動反映這點。
解讀轉換器的輸出
Time Zone Converter 中每一個目標列會提供四項資訊：當地時間、日期、星期幾，以及該時區在被轉換的那個精確 UTC 瞬間所對應的當下 UTC 偏移。日期與星期幾是 Outlook 使用者最常誤讀的兩個欄位。一個在東京時間星期二 22:00 的會議，在 EDT 期間可能對應到紐約當天 09:00，或在 PDT 期間對應到洛杉磯當天 06:00，端視各城市位於換日線的哪一側。轉換器會明確顯示這兩個欄位，讓日期跨日的狀況無可錯過。
UTC 偏移那一欄，是確認 DST 究竟是否在你所轉換的日期生效最簡便的方式。如果你輸入的是 7 月的某個日期，而紐約那一列顯示的是 UTC−4 而不是 UTC−5，就代表日光節約時間正在生效，你的會議時間計算必須採用夏季的偏移。如果同一列在 1 月顯示的是 UTC−5，則代表冬季規則生效。總共有大約三十個涵蓋各大洲的主要 IANA 時區可供選擇，每一個都以城市名稱以及標準或夏令的縮寫標示，因此選擇正確的地區只需要一次點擊，不必手動去查偏移。
常見的 Outlook 排程情境
下列這些情境，是只要漏看一次 DST 調整或日期跨日，就最容易產生錯誤邀請的場景。至於每個情境的精確數字，請把來源的時鐘時間丟進 Time Zone Converter；下方所描述的關係，僅說明每個效果的方向與大致幅度。
| 情境 | 你需要驗證的事項 | 天真算法在何處出錯 |
|---|---|---|
| 與紐約和東京的每週例行電話 | 兩個時區在同一天的當地時間，針對系列會議中的每一場 | 美國與日本的 DST 調整日期不同，所以這兩座城市之間的時差在一年之中並非固定 |
| 針對美國、歐洲與澳洲的網路研討會 | 三個不同的當地時間與星期幾；某些與會者可能已經是星期五，而其他人還在星期四 | 國際換日線會造成日期跨日，因此「星期三」的時段並非在每個地方都是星期三 |
| 以另一個國家當地時間表示的截止期限 | 在你的時區中，該截止期限的當地時間與日期 | 在你時區中的日期，可能相對於發布截止期限的該國，已經是明天或昨天 |
| 橫跨多個時區的旅行日 | 抵達時的當地時間與日期，以及停留期間目的地的 UTC 偏移 | DST 可能會在旅途中開始或結束，進而改變後續通話所使用的偏移 |
一個完整範例：紐約 9:00 AM 轉換到加爾各答
為了具體看到 DST 的效果，我們以一個排定在紐約 9:00 AM 的會議為例，將其轉換到全年維持固定偏移的加爾各答。
同一個時鐘時間，1 月（EST）：
步驟 1：1 月的紐約使用 EST，偏移為 UTC−5。步驟 2：當地 9:00 AM + 5 小時 = 14:00 UTC。步驟 3：加爾各答全年使用 IST，偏移為 UTC+5:30。步驟 4：14:00 UTC + 5:30 = 同一天的 19:30 IST（晚上 7:30）。
同一個時鐘時間，7 月（EDT）：
步驟 1：7 月的紐約使用 EDT，偏移為 UTC−4。步驟 2：當地 9:00 AM + 4 小時 = 13:00 UTC。步驟 3：加爾各答仍然使用 IST，偏移為 UTC+5:30。步驟 4：13:00 UTC + 5:30 = 同一天的 18:30 IST（晚上 6:30）。
紐約同一個 9:00 AM 的時鐘時間，到了加爾各答卻相差一個小時，因為紐約的偏移調整了一個小時，而加爾各答的偏移沒有改變。一個把紐約鎖死在 UTC−5 的轉換器，在 7 月會顯示 19:30，而真正的答案是 18:30。那就是悄悄出錯的一個小時，也就是跨越 DST 界線所排定的 Outlook 邀請被打亂的原因。
Outlook 會議的快速驗證流程
在你送出任何跨越時區的 Outlook 邀請之前，請先把要提議的時段跑一次轉換器。輸入 Outlook 即將為你顯示的日期與時間，在 From zone 設定該時區，在目標標籤中新增每位與會者所在的城市，然後讀取四個欄位 — 當地時間、日期、星期幾、UTC 偏移 — 涵蓋每一個目標。如果任何一個目標的日期或星期幾與你預期不符，那就是把時段往後調整一小時或一天的訊號，而不是送出一封會在錯誤時間送達的邀請。
對於週期性會議，請在系列中每一個 DST 適用區間中至少各驗證一次 — 冬季規則期間一次、夏季規則期間一次，以及每一次切換日當天或緊接其後一次 — 因為 1 月適用的偏移，到了 3 月可能就不再適用。所有運算都在瀏覽器中使用內建的 Intl 日期引擎在本機進行，因此不會上傳任何會議細節、不需要帳號，而且即使在沒有網路連線的情況下，這個工具在頁面載入後仍可繼續運作。對於希望以更通用方式處理任何城市時區變更（而不只是驗證 Outlook 時段）的讀者，相關的姊妹篇從逐一城市切入的角度，介紹了同一個轉換器。