Java系统毫秒是否考虑了闰秒?

Sto*_*lly 9 java time datetime

java函数系统.currentTimeMillis()显然返回自1970年1月1日以来的秒数.然而,根据wikipedia.org/wiki/Leap_second,自1972年以来已经有25个闰秒.这意味着自1970年1月1日以来的实际秒数比原始计算所暗示的多25个秒.是系统.currentTimeMillis()做天真的计算并忽略闰秒?

Jon*_*eet 8

正式来说,它取决于操作系统和实施 - 至少对于Date.来自以下文件java.util.Date:

尽管Date类旨在反映协调世界时(UTC),但它可能不会完全这样做,具体取决于Java虚拟机的主机环境.几乎所有现代操作系统都假设在所有情况下1天= 24×60×60 = 86400秒.然而,在UTC中,每年或每两年大约有一次,称为"闰秒".闰秒总是作为当天的最后一秒添加,并且始终在12月31日或6月30日.例如,由于增加了闰秒,1995年的最后一分钟长61秒.大多数计算机时钟都不够精确,无法反映闰秒的区别.

我怀疑你会发现虽然你的计算机时钟大致与UTC对齐,但这是通过NTP等来定期校正时钟,而不是操作系统真正实现闰秒.

我相信JRE库通常假设86400秒.它使生活变得如此简单,如果你要纠正一个不准确的系统时钟,你也可以通过这种方式纠正闰秒.

你真的想弄清楚你感兴趣的东西.如果你需要一种表示使用闰秒的日期和时间的方法,标准的Java库可能不适合你.就我所知,即使JSR-310也不再支持闰秒(这对大多数开发人员来说是一个非常明智的决定).

  • 我在 Android 4.2 和 Windows 7 上做了一些测试,System.currentTimeMillis() 确实是自 1970 年 1 月 1 日以来的毫秒数,假设每天正好有 86400 秒。因此,确实,闰秒被忽略,但正如您所说,计算机显示正确的时间(包含闰秒),因为它们的时钟会定期校正:-)。 (2认同)

Ste*_*len 7

POSIX要求系统时钟不承认存在闰秒.MS Windows无法保证系统时钟硬件的质量(也不存在),并且它避免了1秒精度的保证.Java不能轻易做任何底层系统拒绝做的事情.操作系统受到国际法规历史的阻碍,导致一个IEEE标准(PTP)需要闰秒而另一个(POSIX)会拒绝它们.