Ask HN: 系统是否准备好迎接首次负闰秒？

# 问HN：系统是否已准备好迎接首次负闰秒？ 来源：https://news.ycombinator.com/item?id=48807108 https://news.ycombinator.com/vote?id=48864858&how=up&goto=item%3Fid%3D48807108 我们正朝着在2035年底之前*做点*不同的事情迈进：https://en.wikipedia.org/wiki/Leap_second#Phase-out_and_future_of_leap_seconds 在我看来，转向“闰分钟”已经足够接近了：也许每50或100年才会出现一次。今天读这篇文章的我们大多数人永远活不到看到闰分钟的那一天，但这已经足够近了，当它真正需要发生时，我们仍然能集体记住这件事。（而且如果到时候我们搞砸了，偏离的时间也只会差一分钟。不算太糟。） 至于“闰小时”：那简直是把问题踢到遥远的未来，以至于我们很可能会完全忘记它。600年是一段极其漫长的时间；到那时社会早已面目全非。对我来说，闰小时在道德上等同于“算了，我们放弃吧”这个选项。 https://news.ycombinator.com/vote?id=48865328&how=up&goto=item%3Fid%3D48807108 > 至于“闰小时”：那简直是把问题踢到遥远的未来，以至于我们很可能会完全忘记它。600年是一段极其漫长的时间；到那时社会早已面目全非。对我来说，闰小时在道德上等同于“算了，我们放弃吧”这个选项。 需要考虑的一点是：时区通常以1小时为单位递增，但划分区域并不一致，这意味着绝大多数人实际上的本地时间已经比他们精确位置的“真实”时间差了好几分钟，有些情况下甚至超过一小时。“放弃”意味着这是一件值得维护的重要事情，而对绝大多数人来说，他们从闰秒甚至闰分钟中得不到任何好处。对人们来说最重要的是大家都能就“现在是什么时间”达成一致，而这在停止执行闰X时反而更容易实现。 话虽如此，闰小时可能永远也不会真正发生，但这并不是什么大问题。等到我们需要闰小时的时候，人们早就已经调整了他们的习惯，那时大概也不值得去做了。 https://news.ycombinator.com/vote?id=48864207&how=up&goto=item%3Fid%3D48807108 那些系统并不对此负责。 上次出现这个问题时，我曾想过“抹平”这一秒，将其分散到一天中的每一秒里，这样就解决了时钟上突然出现一个离散的+/-1秒的问题。 https://news.ycombinator.com/vote?id=48807434&how=up&goto=item%3Fid%3D48807108 系统绝对没有准备好。闰秒本来就是个坏主意，负闰秒更糟。干脆别管它，让漂移自行抵消算了。 https://news.ycombinator.com/vote?id=48864647&how=up&goto=item%3Fid%3D48807108 解释一下为什么负闰秒更糟？直觉上，正常的闰秒会导致更多的问题，或者至少不会更多。 https://news.ycombinator.com/vote?id=48820967&how=up&goto=item%3Fid%3D48807108 负闰秒其实没那么糟。时间向前跳一秒不会像向后跳那样导致多个系统出现时间循环（有些系统还出现过两次！） https://news.ycombinator.com/vote?id=48864336&how=up&goto=item%3Fid%3D48807108 负闰秒有什么更糟的？系统“体验”到的时间就像是冻结了一秒。正闰秒才更糟，因为时间会倒退。 https://news.ycombinator.com/vote?id=48864669&how=up&goto=item%3Fid%3D48807108 假设你按任务运行时间计费。那么如果你的任务耗时-1秒，你会被收0秒、1秒，还是18×10^18秒？ https://news.ycombinator.com/vote?id=48864470&how=up&goto=item%3Fid%3D48807108 既然整个闰秒系统将在2035年之前被逐步淘汰，我怀疑不会有人再去测试它。为了一秒钟没必要节外生枝。 https://news.ycombinator.com/vote?id=48814828&how=up&goto=item%3Fid%3D48807108 抹平处理的精妙之处在于，它将新的一秒均匀分布到一天中的每一秒，这样每一秒只差1/86400秒，完全在NTP的误差范围内。 对于计算机来说，一切都没有变化。 https://news.ycombinator.com/vote?id=48821015&how=up&goto=item%3Fid%3D48807108 抹平处理不那么精妙的地方在于，如果你的NTP守护进程同时从抹平和非抹平的服务器同步时间，结果就不太理想了。 如果他们在传输过程中保持时间精确，或者添加强制性的协议内容以避免为配置了不同闰秒处理方式的NTP守护进程造成混乱，那就更好了。 https://news.ycombinator.com/vote?id=48863984&how=up&goto=item%3Fid%3D48807108 如果你需要低于1毫秒的时间精度，那你大概知道自己该做什么，而且你不会混用不同的NTP服务器（而且我认为你需要PTP）。 https://news.ycombinator.com/vote?id=48864490&how=up&goto=item%3Fid%3D48807108 你可能会这么想。但那些已经运行了十年的老旧服务器往往会带来麻烦。 https://news.ycombinator.com/vote?id=48864357&how=up&goto=item%3Fid%3D48807108 是啊，90%的情况下最简单的解决方案就是使用Google的时间服务，这些问题会被抹平处理掉，因为他们自己内部被坑得够呛，所以自己搞定了。 https://news.ycombinator.com/vote?id=48812133&how=up&goto=item%3Fid%3D48807108 如果既有正闰秒又有负闰秒，那我们到底在折腾什么？向前调一秒，十年后再向后调一秒…… https://news.ycombinator.com/vote?id=48864028&how=up&goto=item%3Fid%3D48807108 从长期来看，地球自转在减速，因此需要进行调整。在短期内（比如10年算是“短期”），自转速度可能加快也可能减慢，但长期趋势是减速。 请注意，这并非支持闰秒的理由——只是我对它们存在理由的理解。 https://news.ycombinator.com/vote?id=48814879&how=up&goto=item%3Fid%3D48807108 我认为我们无法提前预测是否需要闰秒。 如果问题在于“为什么非要让时间与地球绕太阳公转同步”，除了“传统如此”之外，我也没有更好的答案。 https://news.ycombinator.com/vote?id=48864042&how=up&goto=item%3Fid%3D48807108 我们可以设定一个栅格化的下限，比如3分钟或类似的值，然后接受它。 每几千年校正一次3分钟的偏移，似乎比试图理解所有这些关于晃动、地下水管理以及其他与闰秒相关的细枝末节要容易得多。 https://news.ycombinator.com/vote?id=48864652&how=up&goto=item%3Fid%3D48807108 我相当确定这就是计划。目前法律要求将其控制在正午太阳时0.9秒以内（或类似标准），但在2035年将改为±1分钟，这基本上又把问题往后推了一个世纪左右。 我说不如让它累积到15分钟，然后各国可以通过将时区移动15分钟来自行解决。毕竟确保正午太阳时与时钟上的中午一致，正是时区存在的根本目的。 https://news.ycombinator.com/vote?id=48864451&how=up&goto=item%3Fid%3D48807108 我认为我们已经准备好了。gettimeofday() 绝对不应该用来测量时间[1]，但至少对于负闰秒，它是单调递增的。 我们只会遇到一些编写不佳的代码声称一个操作耗时1100毫秒而不是100毫秒。这不好，但不会出现-900毫秒。 好吧，我这么说，但根据我这里的链接，至少F5负载均衡器过去曾使用 gettimeofday 来跟踪TCP连接。而且 libpcap 以墙钟时间传递元数据也很烦人。 [1]https://blog.habets.se/2010/09/gettimeofday-should-never-be-used-to-measure-time.html https://news.ycombinator.com/vote?id=48864819&how=up&goto=item%3Fid%3D48807108 > gettimeofday() 绝对不应该用来测量时间 然而，就算我不知道你指的是哪个平台，我也可以向你保证，在那个平台上 gettimeofday() 肯定被用来测量时间。不幸的是，这就是软件的现状。 https://news.ycombinator.com/vote?id=48863926&how=up&goto=item%3Fid%3D48807108 我想知道有多少系统真的在意？我猜核心NTP服务器能很好地处理这个问题，而大多数系统只是从它们那里获取时间？ GPS卫星可能也能很好地处理，但也许某些消费级甚至工业级GPS接收器不行？也许某些交易系统也有问题？我觉得加密货币系统不太关心。 https://news.ycombinator.com/vote?id=48864160&how=up&goto=item%3Fid%3D48807108 我想知道是否有需要24/7运行且需要监控的东西……例如，如果石油以每秒100升的速率流过管道，那么某个特定的分钟就会有6100升，有人就会因此多收这100升的钱。 但仪表/报告工具会说：“我们每秒测量一次，仪表报告的恒定速率是100升/秒，我们知道一分钟有60秒，所以总共有6000升！” 或者一个用于“每分钟每秒测量值”的数据库有60个字段，但没有地方存放第61次测量值。 https://news.ycombinator.com/vote?id=48864559&how=up&goto=item%3Fid%3D48807108 我曾经参与过用于电力消耗的智能电表项目，它们确实24/7运行。闰秒不是问题，但现在想来，我们遇到过非常类似的情况：夏令时（DST）的鬼把戏！ 比如凌晨2点到3点之间有多长时间？通常是一小时，但有时是两个小时，有时则是零小时。一开始看起来很简单，但这会制造出很多边界情况，你的业务逻辑需要处理这些情况，我们为此开发了一个相当复杂的系统。 https://news.ycombinator.com/vote?id=48864329&how=up&goto=item%3Fid%3D48807108 系统肯定在意，尤其是在金融和交易系统中。 大约十年前，我参与了一个大型NTP“退火”补丁的部署。我们漏掉了几个系统，整体影响大体上被压制了，但有一个运行着老版本JVM的服务器在闰秒切换时直接崩溃了。 那台特定服务器本来就摇摇欲坠，所以并不意外。但还是需要一些应急处理。 https://news.ycombinator.com/vote?id=48864116&how=up&goto=item%3Fid%3D48807108 这个问题在那些使用时间来确定顺序的系统里经常出现，这些系统未能处理所有与时间保持相关的边缘情况，而这只是其中之一。 我曾经参与过一些极其敏感的系统，它们有数千行的C代码专门用于在必要时跨整小时（每秒）处理时间间隙的倾斜。我知道那些代码只假设了“缺失”时间（向前跳）……即使以我现在作为开发者的认知，如果从头重新实现那个系统，并且没有把它放在心上，我敢打赌我会完全忽略“重叠”或“重复”时间的情况。 也许这只是我个人的问题，但我敢打赌，在一些安全攸关的系统中，负责的工程师、QA和规范也都忽略了这一点。 https://news.ycombinator.com/vote?id=48864262&how=up&goto=item%3Fid%3D48807108 GPS使用自己的时间基准，不做闰秒调整。在显示方面，UTC的闰秒偏移量会被发送到接收器，并在需要时加到显示的时间上。 https://news.ycombinator.com/vote?id=48864215&how=up&goto=item%3Fid%3D48807108 最近这里不是有过一次讨论，指出闰秒将在不到10年内被逐步淘汰吗？鉴于IERS几年前就已经拒绝执行负闰秒，如果在这之前真的实施一次负闰秒，我会感到非常惊讶。 https://news.ycombinator.com/vote?id=48809525&how=up&goto=item%3Fid%3D48807108 是啊，但我们考虑的是纳秒级的系统。 仅MiFID 2就要求亚微秒级精度。这比闰秒的1秒要小一百万倍。 NTP的分钟级偏差用来在工作站上显示日期还可以，但对于许多对现代世界至关重要的设备来说就不够了。 https://news.ycombinator.com/vote?id=48864613&how=up&goto=item%3Fid%3D48807108 MiFID 2并不要求纳秒级精度。最严格的情况下大概是100微秒。 某些MiFID报告要求微秒甚至纳秒级的*精度*，但这实际上只是一个格式化要求：“请将时间戳写为小数点后六位数字”。 https://news.ycombinator.com/vote?id=48809746&how=up&goto=item%3Fid%3D48807108 是也不是。 当然，他们有从GPS获取时间的专用时间服务器，但它们需要与世界保持*准确*同步。 但那些被迫使用非常精确计时的公司所采用的时间戳必须与UTC同步。