Unix时间戳实际上跟踪了什么?

Mar*_*oma 11 python datetime unix-timestamp leap-second

我知道Unix时间戳被定义为从那以后经过的秒数1970-01-01 00:00:00Z.但是,我找不到给出这个定义的明确来源.关于闰秒,我还阅读了关于UTC和Unix时间戳之间关系的各种不同陈述.

此维基百科页面包含所有闰秒的列表.第一个是

1972-06-30 23:59:60
Run Code Online (Sandbox Code Playgroud)

关于Unix时间戳的陈述

对于"所有现代计算机系统",Unix时间对于除秒之外的任何事情都是完全无知的.

来源:HackerNews,brazzy

UNIX时间跟踪UTC而不是TAI,这意味着它"纠正"闰秒.因此,UNIX时间不是"自纪元以来的秒数",而是"86400*(自纪元以来的整天数)+(自午夜以来的秒数)",并且UNIX时间将向前(从未到目前为止)和闰秒后退(大多数实现中的第二个将在23:59:60到00:00:00之间重复,因为它们具有相同的时间戳).

来源:黑客新闻,masklinn

我也读过(但是我再也找不到了 - 在Stack Overflow上的某个地方)Unix时间戳假设每天都有24*60*60秒.海报暗示天仍然以某种方式保持同步,而闰秒只是"减慢"真正的秒.因此,"unix时间戳秒"可能不是SI秒.

可能的答案

我可以看到三个可能的答案:

A1:Unix时间戳跟踪自1970-01-01 00:00:00Z以来的SI秒.这意味着他们距离UTC只有27秒.

A2:Unix时间戳跟踪"在TAI中传递秒数".这意味着将Unix时间戳转换为UTC的库必须处理闰秒.

A3:Unix时间戳跟踪"以UTC为单位的秒数".这意味着两个Unix时间戳1之间的差异在大多数情况下可能是1 SI秒,但不是全部.

请在答案中添加来源.

蟒蛇

蟒蛇datetime似乎没有意识到闰秒(?).

>>> import datetime
>>> a = datetime.datetime(1972, 6, 30, 23, 59, 59)
>>> b = datetime.datetime(1972, 7, 1, 0, 0, 0)
>>> b-a
datetime.timedelta(0, 1)
Run Code Online (Sandbox Code Playgroud)

并且time模块似乎在第二个之前映射了实际的闰秒:

>>> import time
>>> t3 = time.mktime((1972, 6, 30, 23, 59, 59, -1, -1, -1))
>>> t4 = time.mktime((1972, 7, 1, 0, 0, 0, -1, -1, -1))
>>> t4 - t3
1.0
>>> t4 = time.mktime((1972, 6, 30, 23, 59, 60, -1, -1, -1))
>>> t4 - t3
1.0
Run Code Online (Sandbox Code Playgroud)

issue23574支持这种印象.

小智 3

A.4.16 自纪元以来的秒数

协调世界时 (UTC) 包括闰秒。然而,在 POSIX 时间(自纪元以来的秒数)中,闰秒被忽略(不应用),以提供一种简单且兼容的计算时间差的方法。因此,尽管其外观如此,分解后的 POSIX 时间不一定是 UTC。[...]

大多数系统的“时间”概念是一个不断增加的值,因此即使在闰秒期间该值也应该增加。然而,大多数系统不仅不跟踪闰秒,而且大多数系统可能不与任何标准时间参考同步。因此,要求以秒表示的时间是不合适的,因为Epoch精确地表示了参考时间与Epoch之间的秒数。

要求允许应用程序将此时间视为代表引用时间和纪元之间的秒数就足够了。系统供应商和系统管理员有责任确保该值代表引用时间与纪元之间的秒数,并尽可能接近该系统上运行的应用程序所需的时间。

来源: http ://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_16