跨时区会议怎么安排？别被夏令时坑到

跨时区会议最容易出错的地方，是只写 UTC+8、UTC-5 这种固定偏移，而不是使用真实城市时区。

偏移只描述某一刻的差值；会议安排需要考虑当地规则，尤其是夏令时。

用城市时区，不要只用偏移

更推荐使用：

• America/New_York
• Europe/London
• Asia/Shanghai
• Asia/Tokyo
• Australia/Sydney

这些 IANA 时区名包含当地夏令时规则。UTC-5 不能说明纽约当前是不是夏令时。

一定要指定日期

同一组城市，在不同月份可能有不同偏移。1 月能正常开的会议，到了 3 月或 11 月可能相差一小时。

所以要转换具体日期和时间，而不是只看“现在相差几小时”。

分享一个源时间

发会议邀请时可以写成：

Tuesday, 10:00 AM America/New_York
London: 3:00 PM
Singapore: 11:00 PM

保留一个源时间，再列出参会者本地时间，最不容易误解。

夏令时才是最容易漏掉的坑

不同国家和地区切换夏令时的日期并不一样。美国、欧洲、澳大利亚和部分南美地区可能在不同周调整时钟，而新加坡、中国、日本等地区不使用夏令时。

这意味着一个循环会议即使没有改时间，也可能让部分参会者本地时间发生变化。2 月适合纽约和伦敦的时间，到了 3 月可能突然对其中一方不友好。

发邀请前检查什么

跨地区发会议邀请前，至少检查这几项：

| 检查项 | 为什么重要 | | -------------- | -------------------------------------- | | 具体日期 | 不同月份的偏移可能不一样。 | | 城市时区 | America/New_York 比 UTC-5 更安全。 | | 参会者本地日期 | 深夜会议可能已经跨到第二天。 | | 循环会议 | 夏令时会影响未来某几次会议。 |

一次性会议可以在正文里列出各地本地时间。循环会议最好再检查一次下一个夏令时切换后的日期。

简短结论

安排跨时区会议时，先确定日期，使用城市时区，给每个参会地区转换时间，并检查夏令时。不要只靠固定 UTC 偏移做长期安排。

参考资料：

• MDN：Intl.DateTimeFormat