为什么"咱们3点见"在跨国协作中总出问题
会议时间只说了一半事实。"三点钟"不附带地点就毫无意义，但分布式团队每天都在这么说，然后纳闷为什么有人早到一小时或晚到一天。只要两个人身处不同时区，一个单纯的时钟时间就不再是共享信息，而是变成了每个参与者都需要自行解开的谜题。
有三件事让跨时区安排日程容易悄悄出错：
- 时区偏移不直观。 印度是UTC+5:30，尼泊尔是UTC+5:45，澳大利亚部分地区也有半小时偏移。如果你在脑子里按整小时计算，那对于地球上相当一部分地区来说，你就算错了。
- 夏令时改变了目标。 两个城市之间的时差不是固定的。伦敦和纽约通常相差五小时，但在每年春秋各有几周，由于两地调整时钟的日期不同，时差会变成四小时或六小时。
- 裸时间隐藏了自身的歧义。 "下午3点"不带时区，等于邀请大家猜测。即便是"下午3点ET（东部时间）"，在时区偏移波动的几周里也会让人困惑。
这些都不是什么罕见情况。这是日常的日程安排，解决方法是一种习惯，而不是需要花钱买来的工具。
避免大多数错误的一个习惯
每次都要标明时区，并且搭配一个城市。
像"UTC+1"这样的偏移量精确但冰冷；大多数人感受不到它。城市名称自动携带了偏移量 和 夏令时规则，因为每个人大致都知道伦敦或纽约在哪里。所以，不要写"咱们15:00见"，而要写：
15:00 伦敦 / 10:00 纽约 / 19:30 孟买 — 7月24日，周四
这一行同时完成了多项任务。它标明了基准时间，为其他参与者翻译了时间，并完全消除了"哪个下午3点？"的问题。没人需要打开转换器就知道自己是否有空。
几个辅助做法能让这个习惯万无一失：
- 对于书面记录——合同、上线时间、事件日志——统一使用UTC。 UTC永远不会因夏令时变动，所以"维护窗口于02:00 UTC开启"在十二月和七月读起来都一样。让每个参与者自行转换到自己的当地时间。
- 在面向人的消息中，优先使用城市名称而非原始偏移量。 "17:00 柏林"能经受住夏令时过渡；"17:00 UTC+2"会在柏林于10月底回退到UTC+1时悄然出错。
- 发送前确认转换。 快速看一眼世界时钟，显示所有参与者的城市并排对比，就能捕捉到日历邀请中常见的相差一小时错误。这只需十秒钟，却能避免一次错过的通话。
如果你经常跨时区安排日程，请保持一个参考文档，列出你经常合作的时区。在一个地方看到当前的偏移量——并在夏令时转换日观察它们的变化——就能把一个抽象规则变成你可以直接读取的东西。
为分布式团队找到重叠时间
最难安排日程的团队是那些横跨三大洲的团队。考虑一个常见情况：工程师在美国西海岸，产品团队在西欧，交付团队在印度。
以下是他们工作日的实际情况（北半球夏季，以UTC表示）：
| 地点 | 当地时间09:00–17:00对应的UTC时间 |
|---|---|
| 美国西海岸（PDT，UTC−7） | 16:00 – 24:00 |
| 西欧（CEST，UTC+2） | 07:00 – 15:00 |
| 印度（IST，UTC+5:30） | 03:30 – 11:30 |
寻找各行之间的重叠区域。欧洲和印度共享一个舒适的上午到下午时段（大约07:00–11:30 UTC）。欧洲和美国西海岸共享一个狭窄的欧洲下午晚些时候时段（16:00–15:00——在高峰时段基本上没有重叠，除非美国同事早开工或欧洲同事晚下班）。印度和美国西海岸几乎完全没有交集。
这就是"追随太阳"团队的不舒服现实：可能没有一个小时能让三个地区的人都舒适地坐在办公桌前。 最佳共享窗口大约在15:00–16:00 UTC，这对应加州的早餐时间、欧洲的下午晚些时候和印度的晚上。总有人要做出一点牺牲。
当重叠时间如此紧张时的实用做法：
- 轮流承受痛苦。 如果每周全员会议必须让某个人难受，那么轮流让哪个地区承担不舒服的时段，而不是总是让同一批人受苦。
- 保护一个锚定小时。 选择一个重叠的一小时，并坚决捍卫它，用于那些真正需要所有人实时参与的会议。不要用它来汇报状态更新。
- 严格限定时间。 当有人在早上7点或晚上9点加入会议时，会议超时是实实在在的代价。公布议程并准时结束。
当没有重叠时，采用异步方式
如果你的团队跨越，比如加州和印度——12.5小时的时差——实际上没有共享的工作时间。强行安排实时会议意味着有人每周都要在晚上10点或早上6点打电话，这是不可持续的。
解决办法是停止将实时会议视为默认选项。将决策放入书面形式，这样就不需要两个人同时清醒：
- 录制短视频演示，而不是现场演讲；对方可以在早上观看。
- 将状态和更新移入共享文档或线程，每个人在自己的工作日内阅读和回复。
- 使用持续的"交接"笔记，让下班的区域把背景信息传递给上班的区域。
异步工作也受益于在不同区域运行独立的计时器——用于评审、专注时段或限时交接。一个多计时器让你可以同时跟踪多个倒计时，而无需在脑海中计算谁的时钟是哪个。
把宝贵的重叠时间留给异步真正无法完成的事情：头脑风暴、棘手的分歧和关系建设。
夏令时：让你栽跟头的陷阱
夏令时是自信的日程安排者栽跟头的地方。规则并不统一：
- 美国和欧盟的更改日期不同。 美国在3月中旬"拨快"时钟，在11月初"拨回"时钟。欧盟在3月的最后一个星期日和10月的最后一个星期日调整。每年有两次，在几周内，纽约-伦敦的时差 不是 通常的五小时。
- 南半球是相反的。 当北半球拨快时钟时，像澳大利亚和智利这样的地方正在拨回时钟。他们的冬天是你的夏天，他们的时钟向相反方向移动。
- 很多地方根本不调整。 亚洲大部分地区，包括印度和中国，以及赤道附近的整个区域，全年保持固定偏移量。日本从不调整。亚利桑那州（大部分地区）也不调整，而美国山区时区的其他地区则调整。
结论不是要记住所有规则。而是要永远不要假设两个城市之间的时差是恒定的，并在3月、10月和11月的转换周左右重新检查偏移量。这正是为什么城市名称优于原始偏移量：一个了解规则的工具会在正确的日期显示正确的时差，这样你就不必自己计算了。
发送前的实用检查清单
在发送任何跨时区邀请之前，请检查以下项目：
- 我是否标注了城市或时区，而不仅仅是裸时钟时间？
- 我是否包含了每个地区参与者的转换时间？
- 对于任何持久性或合同性内容，我是否用UTC记录？
- 会议是否接近夏令时转换日期？如果是，我是否重新验证了偏移量？
- 发送前，我是否对照世界时钟确认了转换？
- 这个会议是否值得某人早起或熬夜——或者应该改为异步进行？
常见问题解答
我应该用UTC还是当地城市时间安排日程？
两者都用，但用途不同。对于持久的书面记录——截止日期、维护窗口、合同——使用UTC，因为它永远不会变动。在面向人的邀请中使用具名城市时间（"15:00 伦敦"），因为人们读取的是自己的当地时间，而不是UTC。
为什么两个城市之间的时差在一年的不同时间会变化？
因为这两个地方观察夏令时的日期不同，或者一个地方观察而另一个地方不观察。伦敦和纽约在一年中的大部分时间相差五小时，但在只有一方调整时钟的几周内，时差会变成四小时或六小时。
如何为分布在三大洲的团队找到公平的会议时间？
将每个人的工作时间映射到UTC，然后寻找重叠区域。通常，唯一的共享窗口会迫使某人进入早间或晚间时段，所以要在各地区之间轮流承担这个负担，并将重叠时间保留给真正需要所有人实时参与的会议。
如果根本没有重叠的工作时间怎么办？
依赖异步工作：录制的演示、共享文档和不要求两人同时清醒的书面交接。将罕见的实时会议保留给头脑风暴和艰难对话。
"下午3点EST"是明确的吗？
不完全是。在夏季，美国东海岸实际上是EDT，而不是EST，所以"下午3点EST"在技术上会差一个小时。使用城市名称——"下午3点 纽约"——可以完全避免这个缩写陷阱。
一旦你明确标明时区并进行检查，跨时区日程安排就不再是头疼的事情。为你的团队城市保持一个世界时钟打开，收藏你经常使用的时区，让工具跟踪偏移量，这样你就可以专注于会议本身。