8

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

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

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

2 回答 2

11

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

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

于 2013-09-15T12:41:15.730 回答
1

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

作为对@ok 关于 dst 效果的回答的补充，System.currentTimeMillis()不计算闰秒。在理论和实践上，它取决于操作系统。由于包含的大多数操作系统和 Java VM 都遵循 POSIX 标准，因此（也由于互操作性和行为兼容性问题）甚至不允许闰秒对System.currentTimeMillis().

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

从下面的讨论更新：

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

此时间源的输出甚至会发生长达数分钟的突然变化（例如，如果 PC 长时间离线）。如果人们要使用这个时间源并在闰秒期间遇到困难问题，那么他们几乎肯定会在这个时间源与外部时间源（如 NTP 服务器）的任何重新同步期间遇到（更困难的）问题。

于 2013-09-17T19:53:15.767 回答