时差不是固定的
时区是一片遵循相同时钟规则的区域，手机和电脑用 IANA 时区数据库里的名称来标识它，比如 Asia/Shanghai、Europe/London。每个时区和协调世界时（UTC）之间有一个偏移量，而很多地方因为夏令时，这个偏移量一年里会变。有些偏移量还不是整小时：印度是 UTC+5:30，尼泊尔是 UTC+5:45。
| 城市 | 1 月 | 4 月 | 夏令时 |
|---|---|---|---|
| 北京 | UTC+8 | UTC+8 | 不实行 |
| 纽约 | UTC−5 | UTC−4 | 3 月第二个周日至 11 月第一个周日 |
| 伦敦 | UTC+0 | UTC+1 | 3 月最后一个周日至 10 月最后一个周日 |
| 悉尼 | UTC+11 | UTC+10 | 10 月第一个周日至 4 月第一个周日 |
| 奥克兰 | UTC+13 | UTC+12 | 9 月最后一个周日至 4 月第一个周日 |
中国从 1992 年起不再实行夏令时，全国统一用北京时间，所以我们和别的城市的时差，变化完全来自对方。悉尼和奥克兰在南半球，夏令时正好在北半球的冬天：北京和悉尼 1 月差 3 小时，4 月只差 2 小时。时区转换工具按时区名称计算，而不是按一个固定的偏移量，所以它总是使用你所选日期当天实际生效的时差。
找出重叠的工作时间
把每位参会者所在的城市加进时区转换工具，选好日期，表格会列出当天每个小时在各城市对应的时间，并把所有城市都处于工作时间（周一到周五 9:00 至 18:00）的时段标出来。以 2026 年 10 月 5 日（周一）为例：
- 北京和伦敦重叠 2 小时：北京 16:00 至 18:00，对应伦敦 9:00 至 11:00。
- 北京和纽约没有重叠。北京 21:00 是纽约当天上午 9:00。
- 伦敦和纽约重叠 4 小时：伦敦 14:00 至 18:00，对应纽约 9:00 至 13:00。
- 北京、伦敦、纽约三地没有共同的工作时间。
找不到共同时段时，总得有人在下班后或上班前参会。比较公平的做法是轮流，而不是让人数最少的那个办公室一直迁就。另一种办法是把会拆开：一场欧洲和亚洲，一场欧洲和美洲，伦敦的同事两场都参加。很多事情其实不必开会，写一份书面更新，让每个办公室在自己的早上看，效果比任何一个时段的电话会都好。
和美国东部的同事或客户开会，北京时间晚上 9 点到 10 点（对方早上 9 点）通常是最现实的选择；和美国西部，则常常约在北京时间早上 8、9 点（对方前一天下午）。注意对方的「今天」可能是我们的「明天」：北京周一早上 9 点，旧金山还是周日傍晚。
每年会乱掉的那几周
欧洲和北美调整时钟的日期不同，所以每年春秋各有几周，平时记住的时差是错的。2026 年，欧洲 10 月 25 日结束夏令时，美国 11 月 1 日结束。假设有一个固定在伦敦时间每周一 15:00 的周会：
| 周一 | 伦敦 | 纽约 | 北京 |
|---|---|---|---|
| 10 月 19 日 | 15:00 | 10:00 | 22:00 |
| 10 月 26 日 | 15:00 | 11:00 | 23:00 |
| 11 月 2 日 | 15:00 | 10:00 | 23:00 |
有一周纽约的同事要晚一小时参会；从 11 月起，北京的同事则一直晚一小时，直到来年春天，因为中国不调时钟。三月的情况正好反过来：2026 年美国 3 月 8 日调快时钟，欧洲 3 月 29 日才调，中间三周伦敦和纽约只差 4 小时，而不是平时的 5 小时。
只要会议是在日历软件里按某一个具体时区创建的，软件都能正确处理这种变化。问题出在有人把时间抄进聊天消息，写成「北京时间 22:00 / 伦敦 15:00」，这段文字不会自己更新。每到切换的那几周之前，用转换工具查一下相关日期，给受影响的人发一条提醒。
不存在的时间和重复的时间
调快时钟的那天凌晨，会跳过一个小时：2026 年 3 月 8 日，纽约的时钟从 2:00 直接跳到 3:00，2:30 这个时刻根本不存在。调慢时钟的那天，有一个小时会重复一次：2026 年 11 月 1 日，纽约的 1:30 会出现两次。选到这两类时间时，转换工具会给出提示，并说明实际采用的是哪一个时刻。定时任务，比如备份、报表、自动提醒，尽量不要排在这几个小时里。
把时间写得没人会误解
- 写城市或时区名，不写缩写。 CST 既可以是中国标准时间（UTC+8），也可以是美国中部标准时间（UTC−6）；IST 在印度、爱尔兰、以色列各有含义。写「北京时间 15:00」或者「伦敦时间 15:00」就不会有歧义。
- 写上日期。 纽约周一上午 9:00 是北京周一晚上 9:00，而洛杉矶周五下午 6:00，东京已经是周六了。
- 用 24 小时制。 英文里「12 am」经常被误解，写「00:00」或者「3 月 3 日零点」就不会。
- 截止时间同时写出 UTC。 「2026 年 10 月 31 日 23:59（UTC）截止」对每个读者都是同一个时刻，他们只需要自己换算一次。
- 给程序看的地方用 ISO 格式： 2026-10-31T23:59:00Z，人和程序都能读懂。
算清离截止日期还有几天
日期计算器回答的是约时间的另一半问题：还有多久，N 天后是几号。从 2026 年 9 月 28 日到 2026 年 12 月 25 日是 88 天，也就是 12 周零 4 天，其中工作日 64 天。2026 年 9 月 28 日往后数 10 个工作日是 10 月 12 日，往后数 30 个自然日是 10 月 28 日。
两个习惯能避免「差一天」的争执。第一，说清楚算不算起始那一天：日期计算器算的是两个日期之间相隔的天数，周一到周二算 1 天。第二，1 月 31 日加一个月，2026 年得到的是 2 月 28 日，因为没有 2 月 31 日；合同和还款计划通常会写明这种情况怎么处理，你写的约定也应该写明。
日期计算器的工作日只排除周六和周日，不考虑法定节假日，更不考虑国内每年的调休。比如上面那个例子，10 个工作日正好跨过国庆假期，实际的第 10 个上班日要晚得多。截止日期靠近节假日时，一定要对照国务院办公厅公布的当年放假安排。临近截止时，倒计时工具可以一直倒数到某个日期和时间，标签页放在后台也不会走偏。注意，倒计时的分享链接里记录的是「几点几分」，不是一个绝对时刻：别的城市的同事打开，会倒数到他们当地的这个钟点。这对「新年零点」正合适；如果是全球统一的截止时刻，先换算好，再让每个人按自己的当地时间设置。
跨时区约时间的检查清单
- 把所有参会者的城市加进转换工具，看的是具体的那一天，而不是「平时」。
- 选一个大家都在工作时间内的时段；没有的话，轮流迁就。
- 在大家都订阅的日历里，按一个具体的时区创建会议。
- 提前检查三月和十月底到十一月初的切换周。
- 书面通知里写清日期、时间和城市（或 UTC），不要只写缩写。
- 会议邀请发出后，请一位其他时区的同事看一眼他日历里显示的时间，确认和你预期的一致，这一步花不了一分钟，却能拦下大多数因为时区设置不对而产生的错误。
局限
- 时区规则来自你的浏览器。 它随浏览器和操作系统更新；如果某国临时修改规则，可能要等下次更新才能反映出来。
- 工作时间固定为周一到周五 9:00 至 18:00。 工作时间或周末不同的团队（比如周日到周四上班的地区），看表格时要自己调整。
- 工作日只排除周末， 不排除法定节假日，也不处理调休。
常见问题
和美国同事开会，北京时间几点比较合适？
和美国东部，一般是北京时间晚上 9 点到 10 点（对方早上 9 点到 10 点）；每年 11 月到次年 3 月美国结束夏令时后，要再晚一小时。和美国西部，常约在北京时间早上 8、9 点。
为什么固定的周会突然差了一小时？
会议固定在某一个城市的时间，而另一个城市在不同的日期调整了夏令时，或者根本不调（比如中国）。
给不同国家的人写截止时间，怎么写最清楚？
写日期、时间，以及城市或 UTC，比如「2026 年 10 月 31 日 23:59（UTC）」。不要只写 CST、IST 这类缩写，它们在不同国家指不同的时区。