為什麼「三點見」跨了國界就出問題
約定一個會議時間，其實只說了一半的事實。「三點鐘」如果沒有附上地點就毫無意義，然而分散各地的團隊每天這樣說，然後納悶為什麼有人早了一小時或晚了一天撥入。當兩個人身處不同時區，一個單純的時鐘時間就不再是共享資訊，而變成每個人各自解讀的小謎題。
三件事讓跨時區排程不知不覺地容易出錯：
- 時差不是直覺的。 印度是 UTC+5:30，尼泊爾是 UTC+5:45，澳洲部分地區也有半小時時差。如果你在腦中假設整數小時來計算，對地球上相當大一部分地區你就會算錯。
- 夏令時間讓目標移動。 兩個城市之間的差距不是固定的。倫敦和紐約通常相差五小時，但在每年春秋的幾週內，它們會變成四或六小時，因為這兩個地區在不同日期調整時鐘。
- 一個裸時間隱藏了自身的模糊性。 「下午3點」沒有時區就是讓人猜。即使是「美東時間下午3點」在時差變動的幾週內也會讓人搞錯。
這些都不是什麼稀奇事。這是日常的排程，而解決方法是一個習慣，不是你需要購買的工具。
一個習慣就能預防大多數錯誤
每次都標明時區，並搭配一個城市。
像「UTC+1」這樣的時差很精確但冰冷；大多數人感受不到它們。城市名稱自動攜帶時差 和 夏令時間規則，因為每個人大致知道倫敦或紐約在哪裡。所以，與其寫「我們15:00見」，不如寫：
15:00 倫敦 / 10:00 紐約 / 19:30 孟買 — 7月24日星期四
這一行同時完成了好幾件事。它標明了錨點時間，為其他參與者轉換了時間，並完全消除了「哪個下午3點？」的問題。沒有人需要打開轉換器才知道自己是否有空。
幾個輔助做法可以讓這個習慣萬無一失：
- 對於書面記錄——合約、上線時間、事件日誌——統一使用 UTC。 UTC 永遠不受夏令時間影響，所以「維護窗口於 02:00 UTC 開啟」在十二月和七月讀起來都一樣。讓每個人自行轉換成自己的當地時間。
- 在面向人的訊息中，偏好使用城市名稱而非原始時差。 「17:00 柏林」能安然度過夏令時間轉換；「17:00 UTC+2」在柏林於十月底調回 UTC+1 時就會默默地變成錯誤。
- 在按下發送前確認轉換。 快速瞥一眼 世界時鐘，顯示所有參與者的城市並排，就能抓出那些日曆邀請著名的差一小時錯誤。這只需要十秒鐘，卻能省下一通錯過的電話。
如果你經常跨地區排程，請保持一個參考資料開啟，列出你最常合作的 時區。在同一個地方看到當前的時差——並在夏令時間轉換日觀察它們的變化——能將一個抽象規則變成你可以直接讀取的資訊。
為分散團隊找到重疊時間
最難排程的團隊是那些橫跨三大洲的團隊。考慮一個常見的組合：工程師在美國西岸，產品在西歐，交付團隊在印度。
以下是他們工作日的實際情況，以 UTC 表示（北半球夏季）：
| 地點 | 當地 09:00–17:00 的 UTC 時間 |
|---|---|
| 美國西岸 (PDT, UTC−7) | 16:00 – 24:00 |
| 西歐 (CEST, UTC+2) | 07:00 – 15:00 |
| 印度 (IST, UTC+5:30) | 03:30 – 11:30 |
尋找各列重疊的地方。歐洲和印度共享一個舒適的上午到下午時段（大約 07:00–11:30 UTC）。歐洲和美國西岸共享一個狹窄的時段，在歐洲的下午晚些時候（16:00–15:00——在尖峰時段基本上沒有重疊，只有當美國人早開始或歐洲人晚下班時才會打開）。印度和美國西岸幾乎沒有交集。
這就是跟隨太陽團隊的殘酷事實：可能沒有一個小時能讓三個地區都舒適地坐在辦公桌前。 最好的共享窗口大約在 15:00–16:00 UTC，這對加州來說是早餐時間，對歐洲來說是下午晚些時候，對印度來說是晚上。總有人要做出小小的犧牲。
當重疊時間如此緊湊時的實用做法：
- 輪流承受痛苦。 如果每週的全員會議必須讓某些人不方便，那就輪流讓不同地區承擔尷尬的時段，而不是總是讓同一群人受苦。
- 保護一個錨點小時。 選一個重疊的小時，並嚴格保護它，用於那些真正需要所有人即時參與的會議。不要把這個時間花在狀態更新上。
- 嚴格控制時間。 當人們在早上7點或晚上9點加入時，會議超時是真正的成本。發布議程並準時結束。
當沒有重疊時間時，轉向非同步
如果你的團隊橫跨，比如說，加州和印度——12.5小時的差距——實際上沒有共享的工作小時。強行舉行即時會議意味著有人每週都在晚上10點或早上6點打電話，這不可持續。
答案是停止將即時會議視為預設選項。將決策推向書面，這樣它們就不依賴於兩個人同時醒著：
- 錄製簡短的影片導覽，而不是即時簡報；另一方在他們的早晨觀看。
- 將狀態和更新移到共享文件或討論串中，每個人在自己的工作日閱讀和回覆。
- 使用一個持續進行的「交接」筆記，讓即將下線的區域可以將背景資訊傳遞給即將上線的區域。
非同步工作也受益於在不同區域運行的獨立計時器——用於審查、專注時段或限時交接。一個 多重計時器 讓你可以同時追蹤多個倒數計時，而無需進行關於誰的時鐘是誰的心算。
將寶貴的重疊時間留給非同步真正無法做到的事情：腦力激盪、艱難的分歧以及建立關係。
夏令時間：那些會絆倒你的陷阱
夏令時間是自信的排程者被挫敗的地方。規則並不統一：
- 美國和歐盟在不同日期調整。 美國在三月中旬「撥快」，十一月初「撥回」。歐盟在三月的最後一個星期日和十月的最後一個星期日調整。每年有幾週，紐約和倫敦的時差 不是 通常的五小時。
- 南半球是相反的。 當北半球撥快時，像澳洲和智利這樣的地方正在撥回。他們的冬天是你的夏天，他們的時鐘朝相反方向移動。
- 許多地方根本不調整。 亞洲大部分地區，包括印度和中國，以及整個赤道附近地區，全年保持固定時差。日本從不調整。亞利桑那州（大部分）也不調整，而美國山區時區的其他地方則調整。
結論不是要記住每一條規則。而是要永遠不要假設兩個城市之間的時差是恆定的，並在三月、十月和十一月的轉換週前後重新檢查時差。這正是城市名稱勝過原始時差的原因：一個知道規則的工具會在你需要的日期顯示正確的時差，這樣你就不必自己計算。
實用的發送前檢查清單
在發送任何跨時區邀請之前，請檢查以下項目：
- 我是否標明了城市或時區，而不只是一個裸時鐘時間？
- 我是否為每個地區的參與者包含了轉換後的時間？
- 對於任何持久性或合約性的事項，我是否以 UTC 記錄？
- 會議是否接近夏令時間轉換日期？如果是，我是否重新驗證了時差？
- 我是否在發送前對照世界時鐘確認了轉換？
- 這個會議值得某人早起或熬夜嗎——還是應該改為非同步？
常見問題
我應該以 UTC 還是當地城市時間排程？
兩者都用，但用途不同。對於持久的書面記錄——截止日期、維護窗口、合約——使用 UTC，因為它永遠不會變。在面向人的邀請中使用具名的城市時間（「15:00 倫敦」），因為人們讀的是自己的牆上時鐘，而不是 UTC。
為什麼兩個城市之間的時差在一年中會變化？
因為這兩個地方在不同的日期實施夏令時間，或者一個實施而另一個不實施。倫敦和紐約一年中大部分時間相差五小時，但在只有一方調整時鐘的幾週內會變成四或六小時。
如何為橫跨三大洲的團隊找到公平的會議時間？
將每個人的工作時間映射到 UTC，並尋找重疊的地方。通常唯一的共享窗口會迫使某人進入早或晚的時段，所以輪流讓不同地區承擔這個負擔，並將重疊時間保留給真正需要所有人即時參與的會議。
如果完全沒有重疊的工作小時怎麼辦？
依賴非同步工作：錄製的導覽、共享文件和書面交接，這些不需要兩個人同時醒著。將罕見的即時會議保留給腦力激盪和艱難的對話。
「美東時間下午3點」是明確的嗎？
不完全是。在夏季，美國東岸實際上是 EDT（夏令時間），而不是 EST（標準時間），所以七月的「美東標準時間下午3點」技術上差了一小時。標明城市——「紐約時間下午3點」——完全避免了縮寫陷阱。
一旦你明確標明時區並檢查它，跨時區排程就不再是頭痛的問題。保持一個 世界時鐘 開啟，顯示你團隊的城市，將你使用的 時區 加入書籤，讓工具追蹤時差，這樣你就可以專注於會議本身。