unix - 数据库中的闰秒处理

Question

作为:

The Unix time number is zero at the Unix epoch, and increases by exactly 86400
per day since the epoch. So it cannot represent leap seconds. The OS will slow 
down the clock to accomodate for this. 

那么，如果我在 DB(毫秒精度)中存储 Unix 纪元(例如 ts)，如何处理以下情况？

如何确保 ts 始终在增加而不是向后？

如何从考虑到闰秒的 db 中准确选择 100s 间隔？

例如

SELECT * FROM events WHERE ts >= T1 and ts < T1 + 100

上面的SQL会返回发生在T1, T1+1, T1+2, ..up to T1+99 的事件，但是由于闰秒，结果可能是错误的，包括1s的闰时间，如何取计入这个？

Answer 1

来自 Joda Time FAQ :

Are leap seconds supported?

Joda-Time does not support leap seconds. Leap seconds can be supported by writing a new, specialized chronology, or by making a few enhancements to the existing ZonedChronology class. In either case, future versions of Joda-Time will not enable leap seconds by default. Most applications have no need for it, and it might have additional performance costs.

来自 IANA/奥尔森 TZDB file on leap seconds :

Although the definition also includes the possibility of dropping seconds ("negative" leap seconds), this has never been done and is unlikely to be necessary in the foreseeable future.

你的第一个问题:

How to make sure the the ts is always increasing and no backward?

一个负闰秒会让你处于相同的时间戳(一个值代表两个经过的秒)，所以如果没有两个负闰秒，你就不能真正倒退。由于看起来不太可能出现负闰秒，因此我认为这是您永远不会真正遇到的问题。

更新:我可以想象时间戳倒退的唯一方法是，如果您使用毫秒精度并遇到下面的行为 #3。

你的第二个问题:

How to select exactly the 100s interval from db which take account into the leap second?

由于您以 UTC 记录时间，因此您的值已经包含闰秒。我知道这听起来可能有悖常理，因为正如您所描述的，按照这个比例，一天正好有 86400 秒(86400000 毫秒)。但他们确实在那里。如果他们不是 - 那么我们将与 TAI 同步，而不是 UTC。那怎么可能呢？好吧，当闰秒发生时，可能会发生一些不同的事情:

如果操作系统和应用程序代码都支持闰秒，那么它确实可以将显示秒显示为 :60或 :61 .但是几乎没有真正的实现，因为编程语言通常只允许几秒钟到 :59。 .

操作系统可能会“卡住”一秒钟，在一整秒钟内给出相同的值。

操作系统可能会前进到 :59.999 ，然后跳回 :59.000重复闰秒所涵盖的时间段。 (感谢@Teo)

操作系统可能会“漂移”或“涂抹”一段时间，一次缓慢地向系统时钟增加几毫秒，直到它完全 catch 额外的秒。

操作系统可能会直接跳过它，什么也不做。您的时钟将不同步，直到下一次通过 NTP 同步。如果恰好在闰秒的那一刻同步，它可能只会将时间设置为 :59或 :00并再次不同步一段时间。

让我们考虑一个真实的例子。值 1341100800000表示 2012 年 7 月 1 日恰好在 UTC 午夜。 (您可以在 this web site 上检查，或者在您的 Java 或 Joda 时间代码中进行验证。)如果我们除以 86400000，我们将得到自 1970 年 1 月 1 日 UTC 以来经过的 15522 天。

该值包括 35 个闰秒，包括 2012 年 6 月 30 日一天结束前一秒发生的闰秒。就好像闰秒根本没有发生过一样。

所以大多数时候，你不需要担心闰秒。假装它们不存在。让您的操作系统以它想要的任何方式处理它们。

如果您需要超精确的时间测量，也许是在科学环境中，那么无论如何您都不应该使用计算机的系统时钟。除了可以保持、延长或忽略闰秒这一事实之外，它的设计目的还不是计时器那么精确。相反，您可能应该使用一些非常专业的计时硬件，例如 this vendor 提供的硬件。 .

更新:如果您正在快速记录事件(每秒许多事件)，并且您的操作系统具有上述 #3 中描述的行为，则您可能需要处理闰秒。在这种情况下，我的建议是不要按时间戳排序，而是考虑保留一个单独的、单调递增的序列号，然后按它排序。

例如，您的数据库中可能已经有一个自动递增的整数 ID。您仍然可以在 where 子句中按时间戳过滤以获取特定日期的数据，但您随后将按 ID 排序，以便事件按顺序排列，即使时间戳不是。

有关其他建议，请参阅 Teo's answer .