🌍 时区会议排期（一个时刻 · 各地钟面 · 真正能开会的几个小时）— 跨时区换算与上班时段扫描

同一个时刻，放在几只钟面前

把一个时刻同时放到几只钟面前看。填一个日期、一个钟面读数，再说清这个读数属于哪个时区——绝大多数排期错误就出在最后这一步：单看"21:00"这四个字符，写下它的人不同，它对应的是三场不同的会。之后每选一座城市，都会拿到它自己的当地时间、星期、UTC 偏移、+1 天 / -1 天 标记，以及这一小时是否落在你设定的工作时段里。

34 个按钮按从西到东排列，所以一排选择读起来像一张地图。浏览器时区数据库认识的其余时区都能按 IANA 名称输入（America/Nuuk、Asia/Urumqi、Europe/Zaporizhzhia），这一点很重要，因为人们口头使用的简称往往是错的。这张表最多放六座城市还看得清。

两个值得认真看的数字

时差跨度是最早的钟面到最晚的钟面之间的距离，它把你自己的时区也算在内：你坐在 UTC，选了加德满都和达尔文，它报的是 9 小时 30 分，不是这两座城市之间的差额。半小时、45 分钟的偏移一律按分钟保留，不会四舍五入成整小时，所以 +05:45、+12:45 维持原样。

最佳偏移来自表格下方的 24 小时扫描：从你锚定的那一刻起逐小时往后数，按"有几座城市正处在上班时段"排序。并列的小时会如实标成并列，而不是抹平；扫描对空结果也是直说的——周六会写"接下来 24 小时里没有任何一个班次能让一处进入这个时段"，因为那种局面需要的是协商，不是把工作时段调宽。

不对应一个时刻的钟面读数

夏令时切换附近，一只钟可能跳过一小时，也可能把同一小时走两遍。这两种情况都照实讲出来，不会悄悄替你挑一个答案：

• 纽约，2026-03-08 的 02:30——春季拨表从 01:59 直接到 03:00，这个读数根本不会出现。排期把锚点定在 03:30，提示里说明了原因。
• 纽约，2026-11-01 的 01:30——秋季回调让这个读数出现两次，分别是 05:30Z 和 06:30Z。排期用第一次，同时把第二次也写出来。
• 某座城市在会议前后 24 小时内要拨表，也会被标出来，因为跨越那几个小时的扫描并不是均匀的。

这里的时区数据库就是浏览器自带的那一份（ICU），所以偏移和你系统时钟的来源是同一个。

它刻意不做的事

它不知道节假日、公司统一放假，也不知道"每个人各有不同的工作时段"这回事——你选的所有城市共用同一个当地时段区间。它也不会替你定时间：只按"有多少人在上班"给小时排序，谁的钟点该被牺牲仍然是你的判断。它不发任何网络请求：没有 API 调用、没有查询、没有提交。日期、读数和选中的城市都不会离开这台设备，离线、直接从磁盘打开也照样能算。