【问题标题】:How does Unix Epoch time behave on a leap smeared clock?Unix Epoch 时间在闰涂抹时钟上的表现如何?
【发布时间】:2019-11-13 10:33:27
【问题描述】:

考虑一台机器,它的时间在闰秒期间存在正午到正午的线性拖尾。

我想知道系统时钟如何在拖影期间提供准确的纪元时间。

例子:

  • 闰秒定于 2016 年 12 月 31 日。

  • 在机器上,12 月 31 日 11:59:00 的 Unix 时间戳为 1483185540

  • 在中午开始拖尾,这意味着下午 1:30 的系统本地时钟已经落后于 TAI 和 UTC 几微秒。 Epoch 时间戳应为 1483191000(正好 1 小时 31 分钟后),由于 Epoch 不考虑闰秒,因此不再精确到 TAI/UTC
  • UTC 在下午 12 点增加一秒:晚上 11:59:60,本地拖尾时钟应正常继续
  • 直到 1 月 1 日中午,全球 UTC 和本地 UTC 再次同步,本地 Epoch 时钟现在比全球 Epoch/TAI 落后整整一秒

如何解决这个不准确的问题?一旦系统知道发生了闰秒,本地 Epoch 时间是否会跳过一秒?或者这个问题是如何处理的?
它是否取决于用于计算时间的时钟的实现?如果是这样,GNU 的 coreutils date 是如何处理这个问题的?

【问题讨论】:

    标签: date time gnu unix-timestamp leap-second


    【解决方案1】:

    不准确没有解决。自 1970-01-01 00:00:00 UTC 以来,Unix 时间仍然是秒计数,不包括插入的闰秒。这样做的好处是可以轻松地将秒数转换为{year, month, day, hour, minute, second} 形式。

    它的问题是,减去跨越闰秒插入的两个 Unix 时间时间点将导致持续时间比实际时间少一秒。

    【讨论】:

    • 所以,只是为了正确理解它:在系统上,纪元时间不是自 1970-1-1 以来的秒数,而是自 1970-1-1 + 1 秒以来,这将导致上述计算不准确与“真实世界”纪元时间戳不同?我选择 Epoch 是为了避免跳跃冲突和不准确,我是否必须添加不能涂抹本地时钟的约束以提供完全准确的时序和差异?
    • 有些人将涂片解释为一个时代的转变。我不。我知道没有任何 API 不会将 0s 的 Unix 时间格式化为 1970-01-01 00:00:00 UTC。如果有一个时代转变,格式化程序必须考虑到这一点,并将 0 格式化为 1970-01-01 00:00:27 UTC。
    • 计算机系统具有单调时钟,可用于避免闰秒拖尾的计时不准确。通常,这些单调时钟与民用日历没有任何关系。它们很像手持秒表:适合计时,不适合计时。
    • @Nicolai Schmid ,与 Posix 时间戳基本相同的 Unix 时间戳总是从 1970 年 1 月 1 日 00:00 开始计算,并且总是从计数中排除闰秒。大多数操作系统和编程语言库在使 Posix 时间戳或任何其他类似的秒计数时间戳可用于执行进程时,都会给出不包括闰秒的值。当您写“我选择 Epoch 以避免跳跃冲突和不准确”时,这句话无法理解。您必须给出一个代码示例,提供语言版本和操作系统的详细信息。
    • 那我详细说一下;一般来说,我更喜欢 Epoch 时间戳而不是 UTC 时间戳,因为我不必担心两个时间戳之间的时间间隔长度不正确,因为 Epoch 没有闰秒的概念但是现在,有了闰涂抹时钟,操作系统和大多数图书馆没有发生闰秒的帐户,因此与 TAI 时间相比,我的 Epoch 时间戳相差一秒。这就是我所指的问题。
    猜你喜欢
    • 2015-06-16
    • 2012-07-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-09-23
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多