System.currentTimeMillis（）返回的值是否受Day Light Savings和Leap Second调整的影响？

Question

我知道System.currentTimeMillis()给出了自纪元以来毫秒级的时间，并且它对系统的挂钟时间很敏感。我也知道不建议使用System.currentTimeMillis()来计算测量时间的程序中的经过时间。 为此目的，Java库提供了System.nanoTime()。

我对System.currentTimeMillis()有两个具体问题：

1. 是否会受到闰秒调整的影响？我认为答案是是因为闰秒会调整系统的挂钟时间。
2. DST （DayLight Savings）打开/关闭时是否会受到影响？当时间从23:59突然变为2:00时会发生什么？由于系统时钟实际发生了变化，我认为答案是是，但我想与社区核实。

Answer 1

System.currentTimeMillis()返回的值是自纪元以来经过的毫秒数。这个毫秒数就是：毫秒数。

假设在某一天，由于DST，您所在的国家/地区决定立即从1:00到2:00。这是否意味着在1:00到2:00之间已经过了1小时？ 0毫秒已经过去了。您所在的国家/地区只是决定将毫秒值X表示为1:00，并将毫秒X + 1表示为2:00。时间的表示不会改变毫秒数。

Answer 2

你的两个问题的明确答案是：不，不。

作为关于dst效果的@ok答案的补充，System.currentTimeMillis()不计算闰秒。在理论和实践中，它取决于操作系统。由于大多数操作系统和Java VM都遵循POSIX标准，后果（也是通过互操作性和行为兼容性问题）甚至不允许闰秒对System.currentTimeMillis()产生任何影响。

您还可以通过将System.currentTimeMillis()（除以1000）的值与您自1972-01-01T00：00：00以来经过的SI秒计算进行比较，轻松验证这一点。差异现在必须是25秒。

以下讨论更新：

闰秒对System.currentTimeMillis()长期没有影响（未计算），但可能在短期内。我认为这是无关紧要的，因为这个时间源不是为了实现高精度和时间稳定性而设计的。

此时间源的输出甚至会在几分钟内发生突然变化（例如，如果电脑长时间处于脱机状态）。如果人们打算使用这个时间源并在闰秒期间遇到难题，那么在使用外部时间源（如NTP服务器）重新同步此时间源期间，他们几乎肯定也会遇到（更难）问题。