Unix纪元时间在存在闰秒的时钟上如何运作？

Question

考虑一台机器，在闰秒期间时间被线性平滑至中午到中午的状态。

我想知道系统时钟在平滑期间如何提供准确的纪元时间。

例如：

- 闰秒计划于2016年12月31日进行。 - 在这台机器上，2016年12月31日11:59:00的Unix时间戳为1483185540。 - 中午时分开始平滑，这意味着系统当地时钟在下午1:30已经比TAI和UTC慢了几微秒。 纪元时间戳应该是1483191000（正好晚了1小时31分钟），不再准确地遵守TAI / UTC，因为纪元不考虑闰秒。 - UTC在12:00添加一个额外的秒：11:59:60 pm，本地平滑的时钟应该继续正常运行。 - 直到1月1日中午全球UTC和当地UTC重新同步，当地纪元时钟现在比全球纪元/ TAI慢一个整秒。

这种不准确性如何解决？ 一旦系统知道闰秒发生，本地纪元时间是否会跳过一秒钟？ 或这个问题如何处理？

这是否取决于用于计算时间的时钟实现？ 如果是这样，GNU的coreutils日期如何处理这个问题？

- Nicolai Schmid

Answer 1

精度问题并没有解决。Unix时间仍然是自1970年01月01日00时00分00秒UTC以来的秒数，不包括插入的闰秒。这样做的好处是将秒的计数轻松转换成{年，月，日，小时，分钟，秒}的形式。

它的问题在于，减去跨越闰秒插入的两个Unix时间点会导致时间持续时间比实际少一秒。

- Howard Hinnant

---

有些人将涂抹解释为一个时代的转变。我不这样认为。我不知道有哪个API不会将Unix时间格式化为0秒，即1970年01月01日00:00:00 UTC。如果存在时代转变，格式化程序就必须考虑到这一点，并将0秒格式化为1970年01月01日00:00:27 UTC。 - Howard Hinnant

计算机系统具有单调时钟，可用于避免闰秒模糊的时间不准确性。通常，这些单调时钟与公历没有任何关系。它们很像手持秒表：适合计时，但不适合看时间。 - Howard Hinnant

FWIW，我已经提出了一个解决方案来修复@NicolaiSchmid提到的新C++2a <chrono>库的问题。将会有一个包含经典Unix时间（包括不忽略闰秒的真正UTC时钟），以及基于TAI和GPS标准的时钟/时间点集合数组供用户选择。现有的<chrono>库还支持一个单调时钟（对于那些不需要与公历有关系的时间戳）。 - Howard Hinnant

取决于“正确”的定义，需要为每个+闰秒添加:60时间戳，并考虑不同的时间尺度（“UTC时间尺度相对于TAI时间尺度在机构记忆中记录的预定场合向后移动了一秒钟”[er，“in the” iers.org] -Dr. Mills），每个跳跃一个。由于几乎所有人类时钟都没有:60，因此模糊会扩散跳跃。 - Andrew

没有60秒的NTP系统会根据NTP规则慢慢调整或步进时钟，或者在日志中添加额外的00或59秒。无论是delta时间（例如"uptime"）还是历史时间戳（例如"boottime"），或者对它们进行手动计算都会偏差一秒。 - Andrew