排跨国会议 / 视频通话的 4 个时区规则:别再让人半夜 3 点开会

你 Slack 上跟 NY 同事说明早 10 点开个会,他没反对。到了时间你上线,他刚睡醒;他以为你说的是美东时间,你以为是北京时间 — 一次会议两人都迟 30 分钟或早 30 分钟,合作开局的沟通成本就这么花掉了。问题的根源不是时间错,是时区没说清楚。

这篇文章给 4 个可复制的规则,下次排跨国会议前过一遍,就不会再让人半夜开会。

30 秒总览

排跨国会议的第一原则:用 IANA 时区名,不用缩写(Asia/Shanghai,不是 CST)
第二原则:带 UTC 双重标注(10:00 北京 (UTC+8) = 22:00 前一天 NY (UTC-5))
第三原则:选择 12-15 小时 UTC 偏移覆盖区,不必全开 24 小时
第四原则:第一次排会前测一遍 DST 切换日,DST 期间偏移会变
用 Piick 时区转换器算任何会议的当地时间,5 个 locale 都覆盖

4 个排会规则

规则 1:用 IANA 时区名,不缩写

缩写误读是排跨国会议第一大坑。CST 这个 3 个字母,在 3 个不同地方意思完全不一样:China Standard Time / Central Standard Time (美国中部) / Central Summer Time (澳大利亚中部)。同一字母,在跨时区群里出现 3 种解释,3 种会议结果。

缩写还有 DST 模糊:PST 可能是 Pacific Standard Time 也可能是冬令时的别名,但缩写本身不告诉你当前是夏令时还是冬令时。

IANA 时区名根本解决这两个问题:Asia/Shanghai 永远是 UTC+8 没有 DST;America/New_York 永远是 UTC-5 冬 / UTC-4 夏;Europe/London 冬令 UTC+0 夏令 UTC+1。IANA 时区名是 机器+人都能懂的统一规范。

实操:每次说会议时间都标 IANA,不只标缩写。如果对方用缩写回,主动纠正:不是 EST,是 America/New_York (冬) / America/New_York 夏令时 (夏)。

速查:UTC 这个时区永远不带 DST,适合做所有时区沟通的锚点。Asia/Shanghai、Asia/Tokyo 都永远不 DST,适合做东亚内部沟通。但任何 American / Europe 国家时区都 DST,跨年沟通必须用 IANA 而不是固定缩写。

规则 2:加 UTC 双重标注

为什么只说本地时间不够:同一个 10:00,在北京是 22:00 前一天的 NY,反之亦然。一个时区永远说不清是什么时刻。

标准做法:10:00 Asia/Shanghai (UTC+8) = 21:00 前一天 America/New_York (UTC-5, DST active)。一次性给两个时区,接收方任选一个对得上的。

UTC 永远是 UTC,不夏令时,不偏移变化,是全球时区沟通的唯一可靠锚点。如果只能选一个时区写,默认写 UTC,任何人都能就地转换。

工具支撑:时区转换器的 UTC 偏移字段会同时显示本地 + UTC,自动派生。输入一次 Asia/Shanghai 的会议时间,所有其他时区的本地时间 + UTC 同步显示。不用自己心算。

日历数据存储:事件数据库存 ISO 8601 + UTC offset,不存本地时间字符串。存本地时间等于把时区信息绑定死到当时的 DST 状态,DST 切换后读出来就错。存 UTC 永远不变,显示时才派生本地。

规则 3:选 12-15 小时 UTC 偏移覆盖,不全开 24 小时

国际会议最佳时段:UTC 12:00-15:00,对应欧洲下午、美东早上、亚洲晚上。这个窗口 3 个 major 时区都不在噩梦时段。

全 24 小时开会的隐性成本:每个时段都能勉强开,实际上是大家都困。美国团队早上 6 点开会、亚洲团队晚上 11 点开会,看似都解决了,实际会议效率降到正常工作时间的 60%。

优化策略:按团队 timezone 分布,选 12-15 小时窗口而不是 24 小时。常用配比:

美国东 + 欧洲:UTC 14:00-17:00 (NY 早上 10 点 / 巴黎下午 4 点)
美国全 + 欧洲:UTC 15:00-17:00 (NY 中午 / 巴黎傍晚 / LA 早上 8 点)
亚洲 + 美东:UTC 21:00-23:00 (亚洲晚上 10 点 / NY 早上 9 点,亚洲团队要适度接受晚开)
亚洲 + 欧洲:UTC 09:00-11:00 (欧洲早上 9 点 / 亚洲下午 4 点)
全球 5 个时区以上:强制 1 周轮一次主办方时区,不要让总部永远 9 点

规则 4:DST 切换前测一遍边界日

DST 不是什么神秘现象,但 US / EU / 加拿大 / 澳大利亚 / 新西兰每年改 2 次,会导致 UTC 偏移变化。2026 年数据:美国 3 月 8 日 spring forward / 11 月 1 日 fall back,EU 3 月 29 日 / 10 月 25 日,新西兰 9 月底开始南半球 DST。

实操:每次排会前,DST 切换日 ±2 周内的会议都要重新算 UTC 偏移。用 cron 排的每周一 10:00 纽约会议,DST 后实际跑的是纽约时间但 UTC 偏移从 -5 变 -4,如果日历只写了 10:00 EST 会一直显示错的时间。

经典踩坑场景:2026 年 3 月 8 日(美 DST 开始) 到 3 月 29 日(EU DST 开始)期间,美国和欧盟 同时在不同偏移,纽约-伦敦差距临时从 5 小时变成 4 小时。这个 3 周窗口期是年底最高错的时候。

工具支撑:unix-timestamp-converter 转换具体 epoch 时 DST 已自动处理,不需要手算。但会议邀请里写的 10:00 EST 可能是去年的 10:00,这种就要看 cron 表达式生成器的 next-runs 时区,它会按当前 DST 重新算。

5 个常见踩坑场景

场景 1:用缩写导致的歧义

真事:2025 年一个 US 公司和上海团队排 9 点会议,CST 误读成 China Standard Time,实际开了 Central Standard Time 的会,上海同事等到 22 点。解法:永远用 IANA zone,不准用缩写。

场景 2:UTC 偏移跟着 DST 变

真事:Q1 排的每周一 10:00 EST 跨 3 月 DST 后变成 10:00 EDT,实际是 11:00 美东。接收端看到日历上 10:00 没变,但实际 UTC 偏移从 -5 变成 -4,会议实际晚 1 小时。解法:周一 10:00 纽约时间,3 月后会变成 10:00 纽约时间但 UTC 偏移从 -5 变 -4,接收端看 UTC 永远不变。

场景 3:跨 DST 切换日的会议

真事:2026 年 3 月 8 日(美 DST 开始)开的会议,跟 3 月 1 日同样的 10:00 EST 在 NY 实际时间差 1 小时,因为 3 月 8 日前是 EST (UTC-5) 之后是 EDT (UTC-4)。解法:DST 切换日 ±1 周的会议,提前发 reminder 重新确认本地时间。

场景 4:cron 定时任务跨时区崩

真事:每天 9:00 给团队发日报的 cron,DST 后变成 8:00 或 10:00 NY 时间,取决于 cron 时区设置。cron 设的是 America/New_York,DST 后 next-runs 时间偏移会变。解法:cron 用 UTC,本地展示用时区转换器派生,cron 服务端永远不偏差。

场景 5:澳大利亚 / 新西兰南半球反季节

真事:跟悉尼团队排 9 月初的 10:00 AEST,南半球 DST 9 月底开始,变成 11:00 AEDT。解法:跨 hemisphere 的会议,DST 切换日附近每次都重新核。