夏令时与日期计算

在大多数日子里，给某一时刻加上 24 小时，会落在第二天同样的钟面时间。但一年有两次，在实行夏令时的地方，情况并非如此。一个地区「往前拨」的那天早晨，钟表会从凌晨 1:59 直接跳到 3:00，于是那个日历日只有 23 小时。「往回拨」的那天早晨，钟表从凌晨 1:59 倒退到 1:00，于是那天延长为 25 小时。一秒的长度并没有任何改变；改变的是我们贴在这些秒上的标签。

这件事之所以要紧，是因为人们当作等同的两种运算，在跨过切换时不再一致。加一个日历日会保持钟面时间不变，让底层的时长灵活地变成 23 或 25 小时。加 24 小时则保持时长不变，让钟面时间漂移一小时。在普通的日子里，这两者给出相同的答案，而这恰恰是为什么它们的差别如此容易被忽略，直到某个倒计时或定时任务偏了一小时才暴露出来。

那两个「不存在」和「重复」的小时

每一次「往前拨」和「往回拨」切换的中心，都有一个古怪的小时，两种失效方式互为镜像。

• 往前拨——消失的一小时。当美国的钟表在凌晨 2:00 往前拨时，那一晚的凌晨 2:30 根本不存在。设在 2:30 的日历提醒或 cron 定时任务没有可供触发的时刻；系统要么跳过它、要么把它挪走，而这两种行为并不一致。
• 往回拨——重复的一小时。当钟表在凌晨 2:00 往回退时，凌晨 1:30 会出现两次——一次在拨动之前，一次在拨动之后。一个「凌晨 1:30」的时间戳若不带明确的偏移量就是有歧义的，而一段长达一小时的事件窗口，在日志里可能看起来像是在倒着走。

两种情形背后的教训是：一个钟面时间加上一个日期，未必足以确定某个唯一的瞬间。你还需要偏移量，而这恰恰是像 America/New_York 这样一个完整时区标识符所提供的。这也正是 AskTheDate 把时区嵌进每一个 URL 的原因，我们在配套指南 时区与 IANA 数据库中作了说明。

切换在什么时候发生

世界上没有统一的夏令时日期。每个司法管辖区自定其时，而两套最主要的规则并不对齐。

有一个细节值得留意。欧盟在整个联盟范围内同时于 UTC 01:00 切换，所以采用中欧时间的国家在当地 02:00 拨动钟表，而爱尔兰在 01:00 拨动——当地时间不同，却是同一个瞬间。相比之下，美国在当地时间凌晨 2:00 切换，所以这一变动是随着全国各时区一个接一个地滚动完成，而非同时发生。

世界上大部分地方并不「往前拨」

夏令时远非普遍现象，很容易从美国和欧洲的经验里过度推广。亚洲大部分地区——包括中国、日本和印度——完全不实行夏令时。非洲大部分地区和南美很大一部分也不实行。对这些地区来说，与 UTC 的偏移量全年不变，这让它们的日期运算更简单，却让与实行夏令时的国家之间的跨境排程更难，因为两者之间的时差一年会变两次。

纽约与伦敦之间短暂缩小的时差

因为美国和欧盟在不同日期切换，两座著名城市之间的时差并不是大多数人以为的那个常数。纽约和伦敦通常相差 5 小时。但美国在 3 月第二个周日往前拨，而英国要到 3 月最后一个周日才拨。在这两个日期之间大约两周的间隔里，纽约已经跳到了前面而伦敦还没有，于是时差缩小到 4 小时。一个原本伦敦同事以为在下午 2:00 的纽约上午 9:00 电话，在那两周里会落在下午 1:00。同样短暂的错位在秋季重演，那时美国比欧盟晚一周往回拨。

如果你需要的是任何给定日期上当前、准确的时差，而不是一条记在脑子里的经验法则， 纽约时区转换器 会依据真实的切换日期解算出结果，而 伦敦时间页面会显示那里此刻的钟面时间。

这对一次计算会——以及不会——造成什么

夏令时会不会破坏一个结果，完全取决于这次计算数的是什么。

• 天数差的计数基本不受影响。AskTheDate 数的是在一个固定时区里跨过了多少个午夜。3 月 1 日到 3 月 31 日之间的日历天数是 30，无论中间有没有夏令时切换，它都保持 30，因为一个 23 小时的日子和一个 25 小时的日子各自仍然恰好包含一个午夜。切换改变的是这些日子有多长，而不是有多少个。
• 以小时计的倒计时会明显地多出或少掉一小时。一个报告「距截止还有 72 小时」的计时器，量的是经过的时长，不是日历天数。让它跨过一个往前拨的夜晚，相对于天真的 72 小时计数，钟面上的截止时刻会「提早」一小时到达；跨过往回拨的夜晚，则晚一小时。什么都没坏——只是小时和天不是一回事。

实用的规则：对任何以整天表示的东西——截止日期、年龄、通知期、相隔天数——在固定时区里数日历天数，夏令时就不再要紧。对任何以小时或分钟表示的东西，要尊重真实的切换，并记住「一天之后」和「24 小时之后」是两个不同的要求。

试一试

好奇在春季拨钟的窗口里两座城市会漂移多少？打开 纽约时区转换器， 用 3 月中旬的某个日期与伦敦对比——时差读作 4 小时，而不是通常的 5，这正是本指南要点的具体呈现。