时区会议规划器
选择一个日期，添加你的城市，一次看清一整天：每个 UTC 小时都换算到每个城市自己的时钟上，并按它落在工作时间、其前后的缓冲时间，还是深夜来着色。然后规划器会指出所有人都在工作的小时——或者，当地球说不行时，指出伤害最小的折中小时。Shanghai、Singapore、London 和 New York 已预先加载，因为正是这个组合会让每个天真的“九点开会吧”计划落空。
列是所选日期以 UTC 计的 24 小时。每个单元格是该时刻在该城市自己时钟上的时间；+1 和 −1 表示该时刻在当地落在第二天或前一天。所有计算都使用你浏览器的 Intl 时区数据——任何城市列表、日期或结果都不会离开你的机器。
如何读懂这个网格
大多数会议工具回答的是错误的问题。它们把一个拟定的时间换算到其他时区，而这只有在你已经知道存在一个好时间之后才有用。排期的问题在于搜索，而不是换算：当四个城市从 UTC+8 到 UTC−5 分布时，可能没有任何一个小时对所有地方都体面，而换算器会乐于确认你选的 09:00 对某位同事来说是 21:00，却不提你时间的 14:00 对他们只是偏早、对你则是上午中段。网格把工具反了过来。一天中的每个小时都是候选，每个城市的本地现实一目了然，而折中——当只有折中可选时——是看着数字选出来的，而不是从通话中的哈欠里发现的。
工作窗口由你来设定，因为“工作时间”是一种政策，而不是自然规律。一支 08:00 开始工作的团队和一支坚决守护 09:00–17:00 的团队会产生不同的网格，而缓冲带正是为它们之间的协商而存在：两侧各两小时，大多数人偶尔可以接受、但没有人应每周接受。当规划器报告最佳折中时，它先按有多少城市完全处于工作时间内对小时排序，再按有多少城市至少处于缓冲时间排序——三个城市在工作、一个城市早起的方案，胜过两个城市在工作、两个城市半夜起床的方案，尽管对较差的工具来说两者都是“无重叠”。
夏令时是网格中会移动的部分。偏移量针对你选择的准确日期计算，使用与你的日历相同的 IANA 规则，规划器还会比较每个时区在该日期前后一周的偏移：有差异就意味着时钟调整临近，你为这个日期得出的任何结论在两周后都可能差一小时。这个警告对在切换周期间设定的周期性会议最为重要，那时美国、欧洲和南半球都在不同的星期天调整。配套文章《找到一个尊重每个时区的会议时间》完整讲解了夏令时的陷阱和重叠的数学。
常见问题
为什么有时根本没有任何重叠？
因为地球是圆的，而工作日是八小时。Shanghai 和 New York 相差十二到十三个小时，所以当一方处于 09:00–17:00 之内时，另一方正值夜晚——没有任何一个 UTC 小时能让双方都在工作。规划器会诚实地说明这一点，然后给出最佳折中小时：先是上班城市最多的那些，其次是在工作或缓冲时间内的城市最多的那些，这样痛苦是被有意识地分摊的，而不是在通话中才发现的。
这些颜色是什么意思？
绿色是工作时间——你设定的窗口，默认是 09:00–17:00。琥珀色是缓冲时间：窗口两侧各两小时，是大多数人偶尔会接受的早开始和晚结束。灰蓝色是夜晚：只应在紧急情况下才要求的时间，绝不能作为固定会议。网格显示所选日期每个 UTC 小时在每个城市的本地小时，当该时刻在当地落在相邻的日历日时，会带有 +1 或 −1 标记。
为什么同一个会议每年有两次会漂移一小时？
夏令时在不同国家在不同日期实施——或者根本不实施。美国比欧洲早几周进入夏令时，而南半球的移动方向相反，所以一月可行的时段到四月可能就差了一小时。当某个时区的 UTC 偏移在你所选日期的一周内发生变化时，规划器会标记出来：那正是周期性会议悄悄对某一方提前或推迟一小时落地的时刻。
我可以添加不在预设列表中的城市吗？
可以。在预设之下还有第二个列表，包含你的浏览器所知道的每一个 IANA 时区——有几百个。选择一个，它就会带着其真实偏移和夏令时规则加入网格，数据直接来自你的操作系统所使用的同一套 Intl 数据。任何东西都不会发送到任何地方；整个计算都在你的浏览器中运行。
周期性会议应该轮换吗？
如果不存在公平的时段，应该——轮换是诚实的解决办法。一个总是让同一城市在 21:00 开的固定会议，是对同一批人的无声征税，他们会停止参加，或者参加时不再敏锐。每月轮换这种痛苦，或者拆成两个交替的时段，并使用本规划器找到的折中小时作为轮换点。重叠的数学在配套文章《找到一个尊重每个时区的会议时间》中。