跨時區週會怎麼寫邀請：城市、日期與跨日標註

開始前先確認

確定這個約定後，再寫首場日期、開始與結束時間、主辦城市或時區、重複範圍，以及其他地區是否跨日。只寫“每週三下午兩點”，讀者無法判斷按哪個地區的星期三，也不知道時差變化後該怎樣參加。

先決定週期會議的時間基準

不存在一種寫法能自動保證所有地區全年都在同樣的本地鐘點開會。先按團隊工作需求決定，再在日曆裏表達對應規則，不要建立完系列後才發現雙方理解不同。

城市時區還包含隨日期適用的規則，不等同於一個永遠固定的UTC偏移。IANA時區數據庫說明介紹了時區與夏令時規則的更新機制，實際會期應使用適用於該日期的信息。

跨日要寫日期，不能只加“次日”

示例：假設甲地在某會期使用UTC+8，乙地使用UTC−7。甲地4月8日09:00對應UTC4月8日01:00；再減7小時，乙地就是4月7日18:00。若會議持續30分鐘，乙地結束時間爲同日18:30。

這個例子中，兩地的會議日期不同。“甲地4月8日09:00—09:30；乙地4月7日18:00—18:30”比只寫“相差15小時”更容易覈對。月份與日期是計算條件，不表示真實城市在某年該日使用這些偏移。

真實邀請還要補全年份和實際城市時區。不要直接把示例的月份套入今年，也不要未經覈對就添加星期幾。主辦方寫“次日”時，接收方若不知道以哪地日期爲準，仍可能理解錯。

邀請裏保留一套明確的主規則

可以使用下面的文字模板，方括號都需要填寫後才能發送：

会议：[会议名称]
首场：[完整日期] [开始时间]—[结束时间]
时间基准：[主办城市及明确时区]
重复：[每周哪一天]，截至[结束日期或复核日期]
规则：[固定主办地当地时间 / 固定UTC时间，二选一]
本次对应时间：[其他城市、完整日期、起止时间]
入口：[已核对的会议入口]

“本次對應時間”只能說明具體那一場，不應被理解爲其他城市整個系列都保持相同鐘點。若需要列後續日期，可補充日曆事件或逐場表格，不要把第一週換算結果重複粘貼到所有月份。

會議目的、準備材料和取消方式可以接在時間說明之後，但不要把時間基準埋在長段備註的末尾。參與者應該很快找到自己需要依據哪條規則。

建立系列後，檢查實際實例

在支持城市時區與重複日程的日曆工具中，確認事件時區符合團隊約定，再查看第一場和後續有代表性的具體日期。如果相關地區存在時區調整，檢查變化前後的實例，而不是隻看系列概要。

如果選擇固定UTC規則，也需要確認事件真的採用UTC基準，而不是在當地時區事件標題裏寫了“UTC”。文字和系統字段應一致；頁面上顯示的本地時間則可能是日曆對查看者時區的換算結果。

不同工具的界面和修改選項不同，本文不提供未經覈驗的固定菜單路徑。遇到顯示差異，先比較事件日期、時區、版本和參與者設備設置，再判斷是否是軟件問題。

改一次會議，不要誤改整個系列

臨時延後某一週時，應明確變更只適用於哪一天，還是從那天起持續生效。修改前讀清工具顯示的作用範圍，修改後再查其他實例有沒有被一起改變。

若團隊決定更換整個週會時間，通知中寫清生效日期和新的基準規則，並確認舊安排如何處理。只在聊天裏說“以後提前一小時”，可能讓跨時區參與者各自按不同基準調整。

更新後請參與者覈對實際日曆中的那一場，而不是繼續根據舊截圖參加。本文沒有修改或發送任何邀請，以上是建立和驗收日程時的檢查方法。

出差時分清事件規則與顯示時區

參會者到了另一城市，設備或日曆的顯示時區可能變化，但這不一定意味着會議本身被改期。先看事件原有基準，再看當前所在地區顯示的時間，不要把顯示變化誤當成主辦方移動會議。

如果日曆與設備時間明顯不一致，可以記錄雙方設置和事件詳情後覈對。不要爲了一個系列直接改全局時區來湊鐘點，那可能影響其他事件的顯示。

除了時區，還要單獨確認節假日、工作時段與參與者安排。換算正確只是時間表達正確，不能證明這個時段對所有人都合適。

當前世界時鐘只能幫助當前比較

需要快速判斷此刻某地是不是深夜，可以查看當前城市時間。準備未來週會時，應回到目標日期計算，不能把今天的時差當成全年參數。本站世界時鐘指南同樣提醒未來會議要在日曆中複覈。

發送前核對五項：規則明確、日期完整、跨日已標、系列範圍正確、文字與日曆一致。邀請被髮出、參與者已接受、雙方顯示時間已覈對，是不同狀態，應按實際完成情況記錄。

需要對照當前多個城市時間時，可打開AI Lab世界時鐘。公開頁面標註9積分解鎖，時間依據設備時鐘和瀏覽器時區數據庫。本文未覈驗未來選日、週期會議、發邀請或同步日曆功能，不把這些任務歸給本站。