你以為約好了週二下午，對方卻在週三凌晨收到提醒。另一位同事準時上線，才發現大家下週才開會。跨國會議最讓人疲累的，往往不是換算那幾個小時，而是每個人都以為自己理解了同一個時間。要把會議排好，需要一起確認日期、當地作息與季節性的時間變動。公平也不代表大家都勉強接受，而是讓不方便的負擔看得見，並且有人負責調整。
先找共同工作時段，再決定誰需要讓一步。
- 使用實際開會日期比較城市，連同當地日期與完整會議長度一起看。
- 遇到夏令時間切換或固定例會，重新確認每一地的上線時間。
- 邀請寫明年月日、開始與結束時間、城市時區，以及當天的 UTC 偏移。
先問實際作息，別急著換算時差
排會的起點是人，不是世界時鐘。請每位必要出席者提供開會當天所在的城市、正常工作時段，以及不能開會的時間。有人九點上班，有人十點才開始工作。有人下午需要接孩子，有人中午固定休息。這些差異都會影響真正可用的交集。
不要只依公司辦公室的位置判斷。一位隸屬倫敦團隊的同事，開會那週可能在臺北出差。如果你沿用通訊錄裡的城市，計算本身即使正確，也可能排出完全不合適的時間。遠距團隊最好在安排重要會議前，再確認一次當週所在地。
接著分清楚誰一定要到場。需要作出決定的人、提供關鍵資訊的人，以及只需要知道結果的人，未必需要同時在線。把所有人都列為必要出席，通常會讓時段交集變小，也容易把會議推到清晨或深夜。
你可以直接問：「你當地哪些時間可以穩定參加三十分鐘？」這比問「晚上能不能配合一下」更容易得到真實答案。也要讓對方知道，不方便可以直說，不需要交代私人生活細節。
用指定日期比較城市，找出完整可用的交集
收到各地作息後，再把城市放進會議規劃工具，選定預計開會的日期，逐一比較當地時間。先看必要出席者的正常工作時段是否重疊，再看其他參與者能否加入。不要拿今天的時差，直接推算幾個月後的會議。
找交集時，要把會議的完整長度算進去。兩地都能在某個整點上線，不代表都能繼續開一小時。如果一位同事十七點下班，十六點四十五分開始的三十分鐘會議，仍有十五分鐘超出他的工作時段。
以下用臺北、東京與新加坡示範。假設三地當天都採用九點至十八點的工作時間，也暫時不扣除午休。把各地工作時段轉成 UTC 後，就能看見共同區間。實際安排時，仍要扣除個人的休息、假日與既有行程。
三地工作時段換算後的共同區間
| 城市 | 範例使用的 UTC 偏移 | 當地工作時間 | 換算為 UTC |
|---|---|---|---|
| 臺北 | UTC+08:00 | 09:00 至 18:00 | 01:00 至 10:00 |
| 東京 | UTC+09:00 | 09:00 至 18:00 | 00:00 至 09:00 |
| 新加坡 | UTC+08:00 | 09:00 至 18:00 | 01:00 至 10:00 |
這個例子的共同區間是 UTC 01:00 至 09:00，也就是臺北與新加坡的九點至十七點、東京的十點至十八點。如果需要一小時，最晚開始時間是 UTC 08:00。交集的終點是會議必須結束的時間，不是最後可以開始的時間。
當城市增加到歐洲與美洲，正常工作時段可能完全沒有共同交集。這不是計算失敗，而是安排方式需要改變。先試著縮短會議、減少必要出席者，或把討論拆成兩場。不要一看到空白交集，就直接把某個人的半夜當成可用時間。
日期要跟著城市走，跨午夜尤其容易看錯
國際會議裡的「週五」，可能不是每個人的週五。同一個瞬間，在某地仍是前一天，在另一地已經是隔天。因此，比較時間時要把當地日期與鐘點放在一起，不能只看二十四小時制的數字。
例如，當某城市的偏移是 UTC-08:00，臺北一月十日的零時三十分，對應該城市一月九日的八時三十分。對臺北來說已經過了午夜，對方卻才準備開始前一天的工作。這也可能讓你認為的平日，落在另一位同事的休假日。
午夜的寫法也要小心。「週五晚上十二點」可能被理解成週五剛開始，也可能被理解成週五結束。直接寫「2027 年 1 月 15 日 00:00，臺北時間」，會比口語描述清楚。如果不是刻意選擇午夜，通常改到更容易辨認的時段更省事。
確認日期時，也要看各地假日。時區工具可以協助對照時間，但時間換算正確，不代表對方當天上班。當地國定假日、公司休假與個人請假，都需要另外確認。跨日時尤其要逐地檢查，不能只查看主辦方那一天的行事曆。
夏令時間會改變時差，城市名稱比固定數字可靠
臺灣讀者容易習慣固定的 UTC+08:00，於是把其他城市也想成固定差幾小時。實際上，部分地區會依季節調整時間。對方進入或結束夏令時間後，即使你自己的鐘沒有改，彼此的時差仍可能改變。
不同地區的切換日期也未必一致。當兩個會議地點都使用夏令時間，仍可能有幾週的時差與平常不同。因此，「我們一直都差七小時」不能當作全年有效的排會規則。
依據時區資料的說明，時區資料庫會因應各地對時區邊界、UTC 偏移與夏令時間規則的政策變動而更新。這也是為什麼長期會議應選擇城市時區，並讓作業系統與行事曆保持更新，而不是永久記住一個時差數字。
以行事曆設定來說，Asia/Taipei 或 America/New_York 這類 IANA 時區識別碼，能指出所使用的地區規則。單寫 UTC-05:00，則只表達一個固定偏移。兩者用途不同。前者適合表達依城市作息安排的例會，後者有助於明確說明某次會議當天的時間。
切換當天還可能出現特殊情況。時鐘往前調時，某段當地時間可能不存在。時鐘往後調時，某段時間可能出現兩次。如果會議真的要安排在當地凌晨附近，請逐次檢查行事曆顯示的日期與偏移，避免只輸入一個看似普通的鐘點。
沒有理想時段時，讓不方便的負擔輪流承擔
公平不是讓每個人都在同一場會議裡受一點苦。比較實用的做法，是先保護大家不能配合的時段，再把可以協商的範圍攤開。例如，有人可以偶爾提早半小時上班，但無法晚上參加。另一位同事則剛好相反。
可以先提供兩至三個候選時段，讓參與者分別回覆「正常工作時間內」、「偶爾可以」或「無法參加」。投票時不要只計算誰有空，也要看某個選項是否讓同一個人持續加班。行事曆空白，不等於對方願意在那個時間工作。
如果會議每週舉行，可以按月輪替較早與較晚的時段。紀錄方式不必複雜，寫下每次由哪一地承擔工作時間外的會議即可。評估時也要看程度，提早十五分鐘和凌晨兩點上線，不能視為相同的配合。
有些會議其實只需要十分鐘作決定，卻因為現場讀資料而延長到一小時。會前先收集意見，並把討論範圍寫清楚，通常更能保護跨時區同事的時間。透過meetin.gs相關服務整理流程時，也應先確定會議目的、議程與後續負責人，再處理邀請發送。
若某位同事只需要提供一項數據，可以讓他事前留言，由主持人帶入討論。若需要會後補看內容，則提供清楚的決策紀錄與待辦事項。錄影是否適合，還要考量與會者同意及組織規定。不能到場的人仍應有回饋管道，否則換個時段也未必能改善參與感。
固定例會要先決定固定的是哪一地時間
「每週三下午三點」還不是完整的例會規則。你需要補上：以哪個城市的下午三點為準？如果固定臺北時間，海外同事的當地上線時間可能隨夏令時間改變。如果固定海外辦公室的當地時間，臺北同事就可能需要調整。
另一種方式是固定 UTC 時間。它能提供一致的時間基準，但使用夏令時間地區的同事，仍可能在不同季節於不同鐘點參加。沒有哪一種設定適用所有團隊。選擇的重點是符合工作需求，並讓參與者知道誰的當地時間會變動。
建立系列會議後，不要只確認第一場。請查看切換前與切換後的場次，也查看不同地區尚未同步切換的過渡週。若排程跨越數月，可以在每季開始、已知切換前，以及成員更換所在地時重新檢查。
邀請內容也可以直接說明：「本例會固定以臺北 15:00 開始，其他城市的當地時間可能隨夏令時間調整。」這句話讓大家知道安排原則。若採輪替制度，則把每個輪替期間的日期寫清楚，避免大家只記住上個月的習慣。
需要修改時，要分清楚是調整單次會議，還是整個系列。一次性的出差與假日，通常只需要改某一場。修改後請更新原本的行事曆邀請，讓接受邀請的人取得相同資訊。只在聊天視窗補一句新時間，容易讓舊提醒繼續生效。
把排會流程收斂成五個動作
如果每次安排都從頭討論，很容易漏掉同樣的細節。可以把流程固定下來，但保留每個人提出限制的空間。以下順序適合一次性的國際會議，也能作為例會建立前的檢查。
- 確認參與者與所在地。先區分必要出席與知會對象，收集當週城市、工作時段，以及無法配合的時間。
- 用實際日期找交集。比較各城市完整的會議時段，檢查開始、結束、跨日與當地假日。
- 提出少量候選時間。優先選工作時間內的方案。沒有交集時，先縮短或拆分會議，再協商例外。
- 確認時區與例會規則。檢查夏令時間，並決定系列會議固定哪一地的當地時間，或固定 UTC 時間。
- 發出可核對的正式邀請。寫明日期、起訖時間、城市時區、UTC 偏移、議程與參與方式，並請必要出席者確認。
候選時段的回覆期限也要明確。可以寫「請在臺北時間 1 月 6 日 17:00 前回覆」，避免「明天下班前」在不同地區變成不同期限。若有人尚未回覆，不要自動把沉默視為同意，尤其候選時間落在他的工作時段之外時。
最後的邀請，要讓人不用猜也不用再問
一份清楚的邀請，應同時照顧人類閱讀與行事曆設定。正文寫完整年月日，採二十四小時制，列出開始與結束時間，再附上城市與當天偏移。跨國溝通盡量避免只寫 CST、IST 這類可能有多種解讀的縮寫。
日期也不要只寫成 01/10。不同閱讀習慣可能把它理解成一月十日或十月一日。使用「2027 年 1 月 10 日」或「2027-01-10」，辨識起來更直接。若列出星期，請確定它與該城市的日期相符。
需要在系統或文件中記錄單一時間點時，時間戳記格式提供包含日期、時間與 UTC 偏移的標準寫法。例如 2027-01-12T15:00:00+08:00，可明確表達臺北當天下午三點對應的時間點。不過，單一時間戳記不會替你決定未來每週例會要遵循哪個城市的季節規則。
下面是一段可以調整使用的邀請文字。當其他城市跨到不同日期時，請為每一地分別寫完整日期，不要共用一個日期標題。
專案決策會議，預計三十分鐘
臺北：2027 年 1 月 12 日，15:00 至 15:30，Asia/Taipei，UTC+08:00。
UTC：2027 年 1 月 12 日，07:00 至 07:30。
東京：2027 年 1 月 12 日，16:00 至 16:30，Asia/Tokyo，UTC+09:00。
目的：確認上線日期與負責人。請於會前閱讀議程，並確認行事曆顯示的當地時間。
正式送出前，先檢查行事曆事件本身的時區設定是否與正文一致。文字寫對了，事件卻選到另一個時區，參與者仍可能收到錯誤提醒。會議連線位置、文件與主持人也要齊全，避免大家好不容易在同一時間上線，還要花十分鐘找資料。
讓下一次邀請少一點熬夜與猜測
安排跨時區會議，不必追求一個永遠適用的完美鐘點。先理解每個人的實際工作時段，再用指定日期比較城市，確認跨日與夏令時間，最後把安排寫成不用猜的邀請。這幾個動作做穩，往返確認就會少很多。
真正需要長期維護的是公平。定期問問同事，現在的時段是否仍適合，輪替是否確實執行，會議能否再短一點。當某次安排需要有人配合，也把這份配合記在心裡，並在下次調整。讓每個人都知道自己的時間受到尊重，跨國合作才更容易持續。