Unix时间和闰秒

Question

Unix时间和闰秒

Cam*_*mpa 32 shell unix-timestamp leap-second

关于Unix(POSIX)时间,维基百科说:

由于它处理闰秒,它既不是时间的线性表示,也不是UTC的真实表示.

但Unix date命令似乎并没有真正意识到它们

$ date -d '@867715199' --utc
Mon Jun 30 23:59:59 UTC 1997
$ date -d '@867715200' --utc
Tue Jul  1 00:00:00 UTC 1997

Run Code Online (Sandbox Code Playgroud)

虽然那里应该有一个闰秒Mon Jun 30 23:59:60 UTC 1997.

这是否意味着只有date命令忽略了闰秒,而Unix时间的概念却没有？

Answer 1

Tho*_*ung 25

每天的秒数被固定用的Unix时间戳.

Unix时代的Unix时间数为零,自纪元以来每天增加86400.

所以它不能代表闰秒.操作系统将减慢时钟以适应这一点.就Unix时间戳而言,闰秒根本就不存在.

@ThomasJung,你的回答是误导/错误的.**1)**Unix时间可以和**确实**代表闰秒,虽然不是毫不含糊.例如,UTC 1998-12-31 23:59:60.25表示为Unix时间915148800.25.如果使用Unix时间戳修复秒数,我们每天将有86400个唯一的整数Unix时间戳.虽然Unix时间戳*每天增加*86400,但这并不意味着我们*每天在Unix时间戳上有*86400秒.由于负闰秒,不是每个实数都是有效的Unix时间戳,而不是每个真实数字. (5认同)
由于正闰秒，..number 是唯一的 Unix 时间戳。**2)** 就 Unix 时间戳而言，闰秒确实存在。如果不这样做，Unix 时间将在闰秒期间冻结，但事实并非如此。 (4认同)
这是 POSIX 规范的明确答案：http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_15 引用：“在 POSIX 时间（自纪元以来的秒数）中，闰秒被忽略（不应用））” (4认同)
Unix 秒允许与“真实”秒不同。Unix 日有 86400s，实际上是 86401 实秒（对于有闰秒的日子）。否则，时钟会像 TAI 一样超前：_TAI 比 UTC 早了 35 秒。35 秒是由 1972 年初 10 秒的初始差异加上 1972 年以来 UTC 中的 25 个闰秒得出的。_ (3认同)
@Campa：TAI 时间一如既往地在闰秒期间继续滴答（每个闰秒都会增加 [TAI - UTC 差异](http://hpiers.obspm.fr/eop-pc/index.php?index=TAI-UTC_tab&lang =en). POSIX 时间是 UTC 时间（不包括闰秒*期间的时刻）。TAI 可以告诉实际经过的 UTC (SI) 秒，POSIX -- UT（地球自转）秒（因为 UTC 与 UT 的误差在 0.9 秒以内）。要查找以 UTC 形式给出的两个事件之间实际经过的秒数，您需要知道每个事件相应的闰秒数，例如 2010-01-01 -- 34 闰秒，2013-01-01 -- 35 闰秒。 (2认同)
@Pacerier：你能提供一个参考说明Unix时间代表闰秒吗？[此页面](http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html)明确表示它没有：*但是，在 POSIX 时间（自纪元以来的秒数）中，闰秒被忽略（没有申请）*。[此页面](http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_14)还说*每天应精确计算86400秒*。 (2认同)
@Jung:请你改编一下"所以它不能代表闰秒_unmbiguously_"？ (2认同)
@Pacerier“如果他们不这样做，Unix时间将在闰秒期间冻结，但事实并非如此。” - 不，它不会冻结，它会向后跳转，但对于将时间戳获取为整数值的软件来说，它看起来就像冻结一样，因为连续两秒报告了相同的整数值。 (2认同)

Answer 2

Nic*_*son 21

Unix时间很容易使用,但有些时间戳不是实时,有些时间戳不是唯一的时间.

也就是说,有一些重复的时间戳代表两个不同的时间秒,因为在unix时间内,第六十秒可能必须重复自己(因为不能有第六十一秒).从理论上讲,它们也可能是未来的缺口,因为第六十秒不一定存在,尽管到目前为止还没有发布跳过闰秒.

unix时间的基本原理:它被定义为易于使用.添加对标准库的闰秒支持是非常棘手的.例如,您想要在数据库中表示20年1月1日.世界上没有人知道该日期在UTC的秒数!日期不能存储为UTC时间戳,因为IAU不知道在接下来的几十年中我们必须添加多少闰秒(它们和随机一样好).那么程序员如何在未来的任何两个日期之间经过的时间长度直到一年或两年才知道呢？Unix时间很简单:我们知道2050年1月1日的时间戳(即80年*一年中的#of秒).UTC一年四季都非常难以使用,而unix时间在闰秒发生的瞬间很难处理.

对于它的价值,我从来没有见过一个同意闰秒的程序员.它们应该被明确废除.

是的，这就是明显的实现。其后果是，每年有很多分钟（当时钟发生偏移时）您的计算机时钟与民用时间不同步数百毫秒。想要稳定秒针的应用程序会被挫败（尽管它们当然应该使用单调时钟），而想要准确的民用时间的应用程序也会被挫败。但没有明智的选择......结论：无论您忽略还是考虑闰秒，它们都是不好的。 (4认同)
不，Unix 时间从来没有闰秒。它与 UTC 同步，也就是说，Unix 时间刻度与 UTC 刻度在同一时刻：第二个具有完全相同的长度，并且它们对齐。有时当 unix 时间滴答时，尽管它的值增加了 2，而 UTC 只增加了 1。Unix 时间比任何具有闰秒的系统都要容易得多，因为闰秒简直就是个笑话。 (3认同)
@Pacerier OK,所以2050年1月1日00:00:00是2524629600.那是什么时间戳？没人知道.这对程序员来说是一个大问题:要么你编写了很多代码,要么做了一些非常草率的编程(根据软件必须遵守的任何规则,这些编程可能都不合法).闰秒和随机一样好,因为我们不知道它们什么时候会来.我们没有任何能够准确预测地球摆动的模型,我们每年都要等待和观察.当然这是确定性的,但这对程序员或IAU都没有帮助. (3认同)
典型的 Unux 系统是否不会忽略闰秒，并且在发现自己领先于所链接的 NTP 服务器时简单地减慢时钟速度？在这种情况下，永远不会有模糊的时间戳，只是暂时不准确。 (3认同)
抱歉，最后一次评论中的愚蠢错误。第三句话应为：“有时，虽然unix时间的值重复了前一秒，但unix时间还是在滴答，而UTC却只增加了一个。 (2认同)
我删除了我的评论.你赢了.如果你想学习,首先要了解概率分布. (2认同)

Answer 3

小智 12

这里和其他地方有很多关于闰秒的讨论，但这并不是一个复杂的问题，因为它与 UTC、GMT、UT1、TAI 或任何其他时间标准没有任何关系。根据定义，POSIX (Unix) 时间是 IEEE Std 1003.1“POSIX”标准指定的时间，可在此处获得。

标准是明确的：POSIX 时间不包括闰秒。

协调世界时 (UTC) 包括闰秒。然而，在 POSIX 时间（自纪元以来的秒数）中，闰秒被忽略（不应用）以提供一种简单且兼容的计算时差的方法。因此，分解的 POSIX 时间不一定是 UTC，尽管它出现了。

该标准详细说明了 POSIX 时间不包括闰秒，特别是：

强制要求一致的实现必须与任何特定的官方时钟具有固定关系（考虑隔离系统，或通过将时钟设置为某个任意时间来执行“重新运行”的系统）实际上是不可能的。

由于闰秒是由委员会决定的，在 POSIX 时间中包含闰秒不仅仅是一个“坏主意”，鉴于该标准允许没有网络访问的符合实现，这是不可能的。

在这个问题的其他地方@Pacerier 已经说过 POSIX 时间确实包括闰秒，并且每个 POSIX 时间可能对应于一个以上的 UTC 时间。虽然这当然是对 POSIX 时间戳的一种可能解释，但这绝不是标准规定的。他的论点在很大程度上相当于黄鼠狼的话，不适用于定义 POSIX 时间的标准。

现在，事情变得复杂了。按照标准的规定，POSIX 时间可能不等同于 UTC 时间：

因此，分解的 POSIX 时间不一定是 UTC，尽管它出现了。

然而，在实践中，确实如此。为了理解这个问题，你必须了解时间标准。GMT 和 UT1 基于地球在宇宙中的天文位置。TAI 基于通过物理（原子）反应测量的在宇宙中经过的实际时间量。在 TAI 中，每一秒都是一个“SI 秒”，它们的长度完全相同。在 UTC 中，每一秒都是 SI 秒，但必要时会添加闰秒以将时钟重新调整回 GMT/UT1 的 0.9 秒以内。GMT 和 UT1 时间标准是由地球在宇宙中的位置和运动的经验测量定义的，这些经验测量不能通过任何方式（无论是科学理论还是近似）进行预测。因此，闰秒也是不可预测的。

现在，POSIX 标准还规定，其目的是让所有 POSIX 时间戳在不同的实现中是可互操作的（意思是相同的）。一种解决方案是让每个人都同意每个 POSIX 秒是 1 SI 秒，在这种情况下，POSIX 时间相当于 TAI（具有指定的纪元），除了他们的原子钟之外，没有人需要联系任何人。然而，我们没有这样做，可能是因为我们希望 POSIX 时间戳是 UTC 时间戳。

使用 POSIX 标准中的一个明显漏洞，实现有意减慢或加快秒数——以便 POSIX 时间不再使用 SI 秒——以便与 UTC 时间保持同步。阅读标准很明显这不是预期的，因为这不能用孤立的系统来完成，因此不能与其他机器互操作（它们的时间戳，没有闰秒，对其他机器来说意味着不同的东西，有闰秒）。读：

[...] 时间名称和秒的解释很重要，因为 Epoch 值在符合标准的系统中保持一致；也就是说，重要的是所有符合标准的系统都将“自纪元以来的 536457599 秒”解释为 59 秒、59 分钟、1986 年 12 月 31 日 23 小时，无论系统对当前时间的想法的准确性如何。给出表达式是为了确保一致的解释，而不是试图指定日历。[...] 这个未指定的秒在持续时间上名义上等于国际系统 (SI) 秒。

允许这种行为的“漏洞”：

请注意，作为实际结果，未指定由某些外部标准测量的秒长。

因此，实现通过故意将其更改为不能在隔离或非参与系统之间互操作的东西来滥用这种自由。或者，该实现可以简单地重复 POSIX 次，就好像没有时间过去一样。有关所有现代实现的详细信息，请参阅此 Unix StackExchange 答案。

呼，这令人困惑好吧......一个真正的脑筋急转弯！

Answer 4

B T*_*B T 6

由于其他两个答案都包含大量误导性信息，因此我将其放入。

Thomas 是对的，每天的 Unix Epoch 时间戳秒数是固定的。这意味着在有闰秒的日子里，午夜前的第二秒（午夜前 UTC 分钟的第 61 秒）被赋予与前一秒相同的时间戳。

如果您愿意，该时间戳将被“重播”。因此，相同的 Unix 时间戳将用于两个真实世界的秒数。这也意味着，如果您获得了分数 unix epochs，则整个秒都会重复。

X86399.0, X86399.5, X86400.0, X86400.5, X86400.0, X86400.5, 那么X86401.0。

所以unix时间不能明确表示闰秒——闰秒时间戳也是前一个真实世界秒的时间戳。

这也意味着“自纪元以来的秒数”这一短语具有极大的误导性。这些不是 SI 秒，而是一些神秘且没有真正精确定义的“POSIX 秒”，其长度随着更多闰秒（或多或少随机）应用而变化。 (4认同)
@Gellweiler 我完全理解它：P。我只是澄清一下，当他们说“自纪元以来的秒数”时，他们并不是在谈论真实的（SI）秒，而只是返回“（小数）天数乘以 86400” - 这无法给出真实的秒数因为有些日子是 86401 秒。但是，是的，如果您确切知道闰秒何时添加，您可以纠正结果 - 所以对于过去它们并不“神秘”。不过，它们有点适合未来，因为我不认为闰秒将永远添加到石头中。 (3认同)
@CarloWood 这是自 1970 年以来的秒数。秒被定义为一天的 1/86400。要获得自 1970 年以来的精确秒数（以 SI 秒为单位），您需要添加 UTC 定义的闰秒。这并不难理解。 (2认同)
当有人说“这并不难理解”而他们看不到这个话题的复杂性时，我总是感到沮丧。 (2认同)

归档时间：	12 年，3 月前
查看次数：	14525 次
最近记录：	5 年，11 月前