Warning: file_get_contents(/data/phpspider/zhask/data//catemap/2/python/320.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Python Unix时间戳实际上跟踪什么?_Python_Datetime_Unix Timestamp_Leap Second - Fatal编程技术网

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

Python Unix时间戳实际上跟踪什么?,python,datetime,unix-timestamp,leap-second,Python,Datetime,Unix Timestamp,Leap Second,我知道Unix时间戳定义为自1970-01-01 00:00:00Z以来经过的秒数。然而,我找不到一个明确的来源来给出这个定义。我还阅读了关于UTC和Unix时间戳之间关于闰秒的关系的各种不同声明 包含所有闰秒的列表。第一个是 1972-06-30 23:59:60 关于Unix时间戳的语句 至于“所有现代计算机系统”,Unix time除了秒之外对任何东西都一无所知 资料来源: UNIX时间跟踪UTC,而不是TAI,这意味着它“校正”了闰秒。因此,UNIX时间不是“自纪元起的秒数”,而是“8

我知道Unix时间戳定义为自
1970-01-01 00:00:00Z
以来经过的秒数。然而,我找不到一个明确的来源来给出这个定义。我还阅读了关于UTC和Unix时间戳之间关于闰秒的关系的各种不同声明

包含所有闰秒的列表。第一个是

1972-06-30 23:59:60
关于Unix时间戳的语句 至于“所有现代计算机系统”,Unix time除了秒之外对任何东西都一无所知

资料来源:

UNIX时间跟踪UTC,而不是TAI,这意味着它“校正”了闰秒。因此,UNIX时间不是“自纪元起的秒数”,而是“86400*(自纪元起的整天数)+(自午夜起的秒数)”,UNIX时间将在闰秒上向前(从未如此)和向后(在大多数实现中,当一天从23:59:60到00:00:00时,一秒将重复,因为它们具有相同的时间戳)

资料来源:

我还读过(但我再也找不到了——在堆栈溢出的某个地方)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之间的差异可能是1si秒,但并非所有情况下都是如此

请在您的答案中添加来源

python 蟒蛇似乎不知道闰秒(?)

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
这一印象得到了许多人的支持

A.4.16秒,从纪元开始

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

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

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


来源:

Unix时间跟踪自UTC 1970-01-01 00:00:00以来经过的SI秒数减去UTC的秒数。正闰秒不计数,负闰秒计数两次。换句话说,它的计算方式好像每天持续86400 SI秒,因此一个Unix时间(86400的倍数)对应于午夜UTC

无闰秒的午夜转换(UTC日持续86400 SI秒):

午夜转换为正闰秒(UTC日持续86401 SI秒);到目前为止已经发生了27天:

UTC       Second #  Unix time (mod 86,400)
--------  --------  ----------------------
23:59:59  86,399th  86,399
23:59:60  86,400th  86,399 <- positive leap second: not counted in Unix time
00:00:00  86,401th  86,400
UTC秒Unix时间(mod 86400) -------- -------- ---------------------- 23:59:59 86399 86399
23:59:60 86400 th 86399您知道有任何可测试的实现可以在1972-06-30上真正纠正闰秒吗?@zvone否-但我对其他库/语言的行为非常感兴趣:-)
UTC       Second #  Unix time (mod 86,400)
--------  --------  ----------------------
23:59:58  86,398th  86,398
23:59:59  86,399th  86,399
00:00:00  86,400th  86,400
UTC       Second #  Unix time (mod 86,400)
--------  --------  ----------------------
23:59:59  86,399th  86,399
23:59:60  86,400th  86,399 <- positive leap second: not counted in Unix time
00:00:00  86,401th  86,400
UTC       Second #  Unix time (mod 86,400)
--------  --------  ----------------------
23:59:57  86,397th  86,397
23:59:58  86,398th  86,398 86,399 <- negative leap second: counted twice in
00:00:00  86,399th  86,400           Unix time