文章
跨时区安排会议
为三个城市的人找到一个合适的会议时间听起来简单，直到时钟变化让所有人迟到一小时。本指南梳理 UTC 偏移量的机制，解释为什么夏令时是排期错误的主要来源，并介绍一种可重复的方法来找到所有参与者都在工作时间内的窗口。
UTC 与偏移量：基础
协调世界时（UTC）是所有民用时间的公共参考点。每个时区都以 UTC 加减若干小时和分钟来表示。纽约冬季为 UTC-5，巴黎冬季为 UTC+1，东京为 UTC+9。当你用 UTC 写出一个时间，世界上任何人都可以在不猜测的情况下将其转换为本地时间。 大多数偏移量是整数小时，但并非全部。印度的时区为 UTC+5:30，这半小时常常让人感到意外。尼泊尔更进一步，为 UTC+5:45，这个 45 分钟的偏移量出于历史和政治原因而存在。澳大利亚部分地区使用 UTC+9:30 和 UTC+10:30。每当你看到一个时区被列为整小时偏移时，请确认：同一地区可能存在不到整小时的时区。 实际规则是将每个日历邀请锚定在 UTC。许多国家的本地时间每年变化两次，UTC 则不会。
夏令时：偏移量为何改变
夏令时（DST）在春季将时钟拨快一小时，秋季再拨回，使一个国家的 UTC 偏移量在数月内偏移一小时。美国在三月第二个星期日和十一月第一个星期日调整时钟。欧洲大部分地区在三月最后一个星期日和十月最后一个星期日调整。澳大利亚位于南半球，在十月和四月调整。许多国家，包括日本、印度、中国以及大多数非洲和东南亚国家，完全不实行夏令时。 结果是每年三月和十月有两至三周的时间，两座城市之间的时差不是你记住的那个数字。纽约和伦敦通常相差五小时；三月的这两三周里则相差四小时，因为美国已经调整时钟而英国还未调整。这是国际日历排期错误的主要来源。 唯一安全的策略是核实会议具体日期的偏移量，而非依赖你上个月记住的偏移量。
寻找重叠时间窗口
写出会议当天每位参与者所在地的 UTC 偏移量。然后为每座城市画一行，标出哪些 UTC 小时对应该城市的 09:00 至 18:00 窗口。所有行的交集就是候选时间段。 具体示例：纽约（冬季 UTC-5）、伦敦（UTC+0）和孟买（UTC+5:30）。伦敦 09:00 为 UTC 09:00，纽约 09:00 为 UTC 14:00，孟买 18:00 为 UTC 12:30。三座城市的工作时间窗口并不存在共同重叠：伦敦和纽约共享 UTC 14:00 至 17:00（对应伦敦 14:00-17:00 和纽约 09:00-12:00），但孟买的工作日在 UTC 12:30 就已经结束，远早于这个窗口开启。总有人不得不接受标准工作时间之外的时段。 这类计算正是本站时区差异工具所处理的。输入两座城市和日期，它会显示偏移量以及该日期是否落在夏令时转换窗口内。
定期会议的实用习惯
在每个邀请中注明时区。写「15:00」是有歧义的；写「15:00 UTC」或「15:00 CET（UTC+1）」可以消除猜测。日历应用程序会将其转换为每位接收者的本地时间，但前提是时区已明确声明。 对于一次性会议，在发送邀请前使用时区转换工具核实具体日期的 UTC 偏移量。对于每周定期会议，检查每个夏令时转换日期时会发生什么。一个固定在「纽约时间 10:00」的会议，每年相对于伦敦参与者会偏移一小时两次。要么接受这种偏移并提前通知参与者，要么将会议固定在 UTC，让每个人的日历在本地自动转换。 许多分布式团队使用的简单惯例：所有会议以 UTC 排期，在邀请正文中附上两三个主要参与时区的本地时间，并在每个夏令时转换前两周添加日历提醒，告知参与者本地时间将变化。世界时钟工具可以让你同时查看多个城市与当前 UTC 时间的对比，这在发送前快速核查时很有用。
在浏览器中本地完成
支撑本文的三个工具完全在你的浏览器中运行。没有任何时间数据、城市名称或日程详情会离开你的设备。 时区转换工具接收日期、时间和源时区，并将其转换为一个或多个目标时区。它会考虑你指定日期的夏令时，因此它显示的偏移量反映该天的实际偏移量，而非该时区的标准偏移量。 世界时钟工具并排显示多个城市的当前时间。这是回答「新加坡现在几点」最快的方式，无需打开搜索引擎。 时区差工具计算两个时区在特定日期的小时差。由于它是日期感知的，能够正确处理两个时区尚未同步调整的转换周。 所有三个工具在页面加载后可离线使用。计算使用你浏览器内置的 IANA 时区数据库，因此夏令时规则与你的浏览器版本一样最新。
本文涉及的工具
常见问题
为什么三月份两座城市之间的时差会变化，即使两者都没有改变时区？
它们在不同日期调整了时钟。当一个国家应用夏令时调整而另一个尚未调整时，两者之间的时差在此期间缩小或扩大一小时。一旦两个国家都完成调整，差值就会恢复正常。
印度位于 UTC+5:30，它有夏令时吗？
没有。印度自 1945 年起就不再实行夏令时。UTC+5:30 的偏移量全年保持不变。尼泊尔位于 UTC+5:45，同样不实行夏令时。这使得与南亚参与者安排时间比与欧洲或北美参与者安排时间更可预测。
发送会议邀请时用 UTC 还是组织者的本地时间更好？
对于国际会议，UTC 更安全。大多数日历应用程序会在源时区明确声明的情况下将邀请显示为接收者的本地时间，而 UTC 永远不会偏移。如果你用东部时间等实行夏令时的时区发送邀请，在不同日期调整时钟的时区的接收者，在转换前后几周可能看到错误的本地时间。