java函数System。 currentTimeMillis （）显然返回自1970年1月1日以来的秒数。但是，根据wikipedia.org/wiki/Leap_second，自1972年以来已经有25个闰秒。这意味着自1970年1月1日以来的实际秒数比原始计算所暗示的多25个秒。是不是系统。 currentTimeMillis （）做了天真的计算并忽略了闰秒？
答案 0 :(得分：8)
正式来说，这取决于操作系统和实施 - 至少对Date而言。来自java.util.Date的文档：
虽然Date类旨在反映协调世界时（UTC），但它可能不会完全这样做，具体取决于Java虚拟机的主机环境。几乎所有现代操作系统都假设在所有情况下1天= 24×60×60 = 86400秒。然而，在UTC中，每年或每两年大约有一次，称为“闰秒”。闰秒总是作为当天的最后一秒添加，并且始终在12月31日或6月30日。例如，由于增加了闰秒，1995年的最后一分钟长61秒。大多数计算机时钟都不够准确，无法反映闰秒的区别。
我怀疑你会发现虽然你的计算机时钟大致与UTC保持一致，但这是通过NTP等来定期校正时钟，而不是OS 实际实现闰秒。
我相信JRE库通常做假设是第86400秒。它使生活如此更加简单，如果你要纠正一个不准确的系统时钟，你也可以纠正闰秒。
你真的想弄清楚你感兴趣的东西。如果你需要一种表示使用闰秒的日期和时间的方法，标准的Java库可能不适合你。据我所知，即使JSR-310也不再支持闰秒（这对大多数开发人员来说是一个非常明智的决定）。
答案 1 :(得分：7)
POSIX要求系统时钟不承认存在闰秒。 MS Windows无法保证系统时钟硬件的质量（也不存在），并且它避免了1秒精度的保证。 Java不能轻易做任何底层系统拒绝做的事情。操作系统受到international regulations历史的阻碍，导致一个IEEE标准（PTP）需要闰秒而另一个（POSIX）会拒绝它们。
答案 2 :(得分：3)
检查是否计算闰秒的一种简单方法是计算当前年度任何给定日期00:00以来经过的秒数。
如果该秒数与00模60一致，则闰秒不计算在2013年，您的模数应为25（考虑到过去的25个闰秒）。
答案 3 :(得分：1)
查看当前TimeMillis（）的Javadoc，它引用了documentation of the Date class，这可以这样说：
虽然Date类旨在反映协调世界时（UTC），但它可能不会完全这样做，具体取决于Java虚拟机的主机环境。几乎所有现代操作系统都假设在所有情况下1天= 24×60×60 = 86400秒。然而，在UTC中，每年或每两年大约有一次，称为“闰秒”。闰秒总是作为当天的最后一秒添加，并且始终在12月31日或6月30日。例如，由于增加了闰秒，1995年的最后一分钟长61秒。大多数计算机时钟都不够准确，无法反映闰秒的区别。
所以回答你的问题：是的，闰秒计算在内。
答案 4 :(得分：1)
我在javarepl做了一个小实验：
java> new Date(1000L * 86400 * (365 * 4 + 1) * 12)
java.util.Date res0 = Mon Jan 01 00:00:00 UTC 2018
正如你所看到的，一个简单的＆＃34;天真的＆＃34;使用的算法只是闰年，而不是闰秒。没有额外的秒数被添加或减去。
更新
新的Instant类相同：
java> Instant.ofEpochMilli(1000L * 86400 * (365 * 4 + 1) * 12)
java.time.Instant res0 = 2018-01-01T00:00:00Z