時區會議規劃器
選擇一個日期，加入你的城市，一次看清一整天：每個 UTC 小時都換算到每個城市自己的時鐘上，並按它落在工作時間、其前後的緩衝時間，還是深夜來著色。然後規劃器會指出所有人都在工作的小時——或者，當地球說不行時，指出傷害最小的折衷小時。Shanghai、Singapore、London 和 New York 已預先載入，因為正是這個組合會讓每個天真的「九點開會吧」計畫落空。
欄是所選日期以 UTC 計的 24 小時。每個儲存格是該時刻在該城市自己時鐘上的時間；+1 和 −1 表示該時刻在當地落在第二天或前一天。所有計算都使用你瀏覽器的 Intl 時區資料——任何城市清單、日期或結果都不會離開你的機器。
如何讀懂這個網格
大多數會議工具回答的是錯誤的問題。它們把一個擬定的時間換算到其他時區，而這只有在你已經知道存在一個好時間之後才有用。排期的問題在於搜尋，而不是換算：當四個城市從 UTC+8 到 UTC−5 分布時，可能沒有任何一個小時對所有地方都體面，而換算器會樂於確認你選的 09:00 對某位同事來說是 21:00，卻不提你時間的 14:00 對他們只是偏早、對你則是上午中段。網格把工具反了過來。一天中的每個小時都是候選，每個城市的本地現實一目了然，而折衷——當只有折衷可選時——是看著數字選出來的，而不是從通話中的哈欠裡發現的。
工作時段由你來設定，因為「工作時間」是一種政策，而不是自然規律。一支 08:00 開始工作的團隊和一支堅決守護 09:00–17:00 的團隊會產生不同的網格，而緩衝帶正是為它們之間的協商而存在：兩側各兩小時，大多數人偶爾可以接受、但沒有人應每週接受。當規劃器報告最佳折衷時，它先按有多少城市完全處於工作時間內對小時排序，再按有多少城市至少處於緩衝時間排序——三個城市在工作、一個城市早起的方案，勝過兩個城市在工作、兩個城市半夜起床的方案，儘管對較差的工具來說兩者都是「無重疊」。
夏令時間是網格中會移動的部分。偏移量針對你選擇的準確日期計算，使用與你的日曆相同的 IANA 規則，規劃器還會比較每個時區在該日期前後一週的偏移：有差異就意味著時鐘調整臨近，你為這個日期得出的任何結論在兩週後都可能差一小時。這個警告對在切換週間設定的週期性會議最為重要，那時美國、歐洲和南半球都在不同的星期天調整。配套文章《找到一個尊重每個時區的會議時間》完整講解了夏令時間的陷阱和重疊的數學。
常見問題
為什麼有時根本沒有任何重疊？
因為地球是圓的，而工作日是八小時。Shanghai 和 New York 相差十二到十三個小時，所以當一方處於 09:00–17:00 之內時，另一方正值夜晚——沒有任何一個 UTC 小時能讓雙方都在工作。規劃器會誠實地說明這一點，然後給出最佳折衷小時：先是上班城市最多的那些，其次是在工作或緩衝時間內的城市最多的那些，這樣痛苦是被有意識地分攤的，而不是在通話中才發現的。
這些顏色是什麼意思？
綠色是工作時間——你設定的時段，預設是 09:00–17:00。琥珀色是緩衝時間：時段兩側各兩小時，是大多數人偶爾會接受的早開始和晚結束。灰藍色是夜晚：只應在緊急情況下才要求的時間，絕不能作為固定會議。網格顯示所選日期每個 UTC 小時在每個城市的本地小時，當該時刻在當地落在相鄰的日曆日時，會帶有 +1 或 −1 標記。
為什麼同一個會議每年有兩次會漂移一小時？
夏令時間在不同國家在不同日期實施——或者根本不實施。美國比歐洲早幾週進入夏令時間，而南半球的移動方向相反，所以一月可行的時段到四月可能就差了一小時。當某個時區的 UTC 偏移在你所選日期的一週內發生變化時，規劃器會標記出來：那正是週期性會議悄悄對某一方提前或推遲一小時落地的時刻。
我可以加入不在預設清單中的城市嗎？
可以。在預設之下還有第二個清單，包含你的瀏覽器所知道的每一個 IANA 時區——有幾百個。選擇一個，它就會帶著其真實偏移和夏令時間規則加入網格，資料直接來自你的作業系統所使用的同一套 Intl 資料。任何東西都不會傳送到任何地方；整個計算都在你的瀏覽器中執行。
週期性會議應該輪換嗎？
如果不存在公平的時段，應該——輪換是誠實的解決辦法。一個總是讓同一城市在 21:00 開的固定會議，是對同一批人的無聲徵稅，他們會停止參加，或者參加時不再敏銳。每月輪換這種痛苦，或者拆成兩個交替的時段，並使用本規劃器找到的折衷小時作為輪換點。重疊的數學在配套文章《找到一個尊重每個時區的會議時間》中。