问正确处理Leap Second

EN

让我们来看看java.util.Date的源代码

public Date() {
    this(System.currentTimeMillis());
}

所以这个问题可以理解为：

System.currentTimeMillis()是否会产生60甚至61的闰秒值(如规范所伪装的)？

答案是严格意义上的:它取决于底层的操作系统。但事实是:所有众所周知的操作系统，如Windows、Linux、Apple、Android，都是对闰秒一无所知。相反，这些操作系统可以在任何时间进行任何时钟操作(回调等，与NTP-server同步...)。顺便说一下，使用协调世界时Date**-API.**，你不会观察到闰秒，值61是不可能的，因为-标准规定，协调时与UT1的偏差不会超过0.9秒，从而导致不会插入双闰秒。

"61“的起源只是对早期POSIX规范的一个严重误解(这个错误现在已经得到纠正)。不幸的是，旧的Java-spec还没有被纠正，直到现在才引起误解。

关于Java-8的：

是的，所谓的"Java时标“被正式指定为UTC-SLS -基于一个过期的提案，该提案的目的是针对NTP服务器的内部实现。现实世界中不存在UTC-SLS的实现。即使是UTC-SLS Java-8也没有实现-SLS。有两个事实证明了这一点：

UTC 8不包含leap second表(这将是任何-

• 实现的基础)。Threeten项目最初拥有这样的一个，但它被删除了(现在也是removed from the backport).
• The从java.util.Date到Instant的转换只有1:1 )(参见源代码-抛开不同精度的millis和nanos)。请注意，在Instant的应用编程接口中没有提到所谓的“java.util.Date Time scale”。

Java time-scale用于所有的date-time类。这包括Instant、LocalDate、LocalTime、OffsetDateTime、ZonedDateTime和Duration。

此外，java.util.Date起源于1995年(当时Java被发明)，而UTC-SLS是在几年后提出的。

那么在Java-8中还剩下什么作为leap second支持呢？规范中的空词造成了很大的混乱，仅此而已。

还能做什么呢？在JDK的范围内什么也不能做。您需要的是一个内置了leap second数据的外部第三方库。我的库Time4J就是一个例子-请参阅此article。另一个选择可能是带有类UTCInstant的库Threeten-Extra。但我还没有测试它到java.util.Date的转换(似乎是可疑的？)。

根据Java8 documentation for the Date class，在闰秒期间调用日期将/did正确返回:60或:61。

所以你不需要做任何事。

然而，它是如何做到这一点是有点神秘的，因为底层的Instant class在一天的最后1000秒中传播了闰秒-所以最后几秒钟中的每一秒实际上都是1.001秒长-并且您的应用程序不知道它是否在闰秒中。