问题标签 [leap-second]

似乎检查它是否是 xx:00:00 UTC/GMT 就像检查 if 一样简单 timestamp % 3600 == 0，时间戳 = 自纪元(1970-01-01 00:00:00) 以来经过的秒数。我们可以在这里看到：

但这不是与闰秒矛盾吗？实际上，从 1970-01-01 00:00:00 到 2016-07-18 02:00:00 之间经过的秒数不是 3600 的倍数，而是3600 + 26 闰秒的倍数（有 26 1972 年到现在之间的闰秒）。

更准确地说：1970-01-01 00:00:00 和 2016-07-18 02:00:00 之间经过的秒数 is3600*24*17000 + 26 和 not3600*24*17000。

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

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

关于 Unix 时间戳的声明

至于“所有现代计算机系统”，Unix 时间除了秒之外，什么都不懂。

资料来源：HackerNews，brazzy

UNIX 时间跟踪 UTC 而不是 TAI，这意味着它“更正”了闰秒。结果，UNIX时间不是“自纪元以来的秒数”而是“86400 *（自纪元以来的整天数）+（自午夜以来的秒数）”，并且UNIX时间将向前（从未如此）和在闰秒后倒退（在大多数实现中，当一天从 23:59:60 到 00:00:00 时会重复一秒，因为它们具有相同的时间戳）。

资料来源：黑客新闻，masklinn

我也读过（但我再也找不到它了——在 Stack Overflow 上的某个地方）Unix Timestamps 假设每天正好有 24*60*60 秒。海报暗示日子仍然以某种方式保持同步，而闰秒只是“减慢”真正的秒。因此，“unix 时间戳秒”可能不是 SI 秒。

可能的答案

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

A1：Unix 时间戳跟踪自 1970-01-01 00:00:00Z 以来的 SI 秒。这意味着它们与 UTC 相差 27 秒。

A2：Unix 时间戳跟踪“在 TAI 中经过的秒数”。这意味着将 Unix 时间戳转换为 UTC 的库必须处理闰秒。

A3：Unix Timestamps 跟踪“在 UTC 中经过的秒数”。这意味着在大多数情况下，两个 Unix 时间戳之间的差异 1 可能是 1 SI 秒，但并非全部如此。

请为您的答案添加来源。

Python

蟒蛇datetime似乎不知道闰秒（？）。

并且该time模块似乎将实际的闰秒映射到前一秒：

issue23574支持此印象。

在我的 golang 应用程序中，我使用 Unix 秒分辨率时间戳（使用 生成time.Now().UTC().Unix()）作为用于请求身份验证的哈希函数中盐的一部分。

希望将此时间戳存储在数据存储中，其中约定是由 golang RFC3339Nano 函数生成的 RFC3339 纳秒分辨率时间戳字符串，以及用于身份验证的哈希。

问题：如果哈希需要稍后重新验证，是否存在无法将 RFC3339Nano 完全反转为原始 Unix 时间戳的风险？

我知道闰秒存在一些适用于 Unix 时间戳的问题。是否有可能通过 RFC3339Nano 往返会导致不同的时间戳，从而错误地使签名无效？

RFC3339Nano 时间戳和 Unix 时间戳是从同一个 time.Time 结构中生成的。

我倾向于认为它会起作用，因为闰秒在它们发生之日产生了额外的 61 秒，我希望它会映射回与前一秒相同的 Unix 时间戳。反过来显然会失败。

2012 年，这里有一个关于 SO 的问题，.NET 的 DateTime 是否能够识别闰秒。[1] 答案是否定的。

该文档仍然明确指出它不是。[2]

但是，Windows Server 2019 和 2018 年 10 月 10 日的 Windows 更新使Windows 本身具有闰秒意识。[3]

这就引出了一个问题：.NET 现在是否天生具有闰秒意识？更具体地说：我是否可以通过某种方式选择加入，让我的DateTime结构也能感知秒级？

编辑：

来自题为“任务：在 Windows 上编写闰秒感知应用程序”[4]（我强调）的 MS Word 文档：

已知问题：已知某些框架会在闰秒发生后错误地计算时间。例如，.NET Framework 使用它自己的内部逻辑来确定现在是什么时间。它的逻辑不考虑闰秒。因此，在操作系统引入闰秒后，“System.DateTime.Now.ToString()”的输出将比本地系统时间提前一秒。 （我们正在与 .NET 框架团队合作。）

从[5]：

众所周知，某些应用程序通过假设一分钟总有 60 秒来错误地计算时间。由于闰秒可以改变这种行为，他们将不正确地记录此事件期间的时间。例如（在撰写本文时）：

.NET Framework 使用自己的内部逻辑来确定现在是什么时间，并且不考虑闰秒。因此，依赖 .NET Framework 的 PowerShell 在使用 Get-Date 时不会报告第 61 秒（数字 60）

事件查看器：事件的日期将被错误记录。但是，事件元数据会正确记录系统时间（显示第 60 秒）。

注意：这些团队正在努力更新他们的软件，以便在处理闰秒时使用更合适的数学。

因此，.NET 似乎会在未来的某个时间意识到闰秒。因此，我不会将此作为解决方案发布。

[1] .Net 的 DateTime 方法是否能够识别闰秒？

[2] https://docs.microsoft.com/en-us/dotnet/api/system.datetime.ticks?redirectedfrom=MSDN&view=netframework-4.8#System_DateTime_Ticks

[3] https://support.microsoft.com/en-us/help/2722715/support-for-the-leap-second

[4] https://aka.ms/Dev-LeapSecond (MS Word)

[5] https://aka.ms/ITPro-LeapSecond (MS Word)

所以我刚刚了解了闰秒，起初我想“哦，好吧，只需使用 unix 时间戳”然后我读到他们根据一天中的特定秒数调整闰秒以使其与太阳对齐. 见鬼？！

所以我想这不好。是否有严格基于自 1970 年 1 月第一个午夜以来的秒数的时间格式，或某个类似的锚点时间，它不会尝试与我们星球的不稳定自转同步？

编辑：动机：无论一天中的时间或时区如何，都有准确的时间，并且不可能有一个模棱两可的时间。坦率地说，我很惊讶这不是事实，听起来无论谁决定在闰秒中添加，都没有考虑到他们在软件中添加了不必要的小错误。

我看了一下 cppreference.org （重点是我的）：

时钟std::chrono::utc_clock是表示协调世界时 (UTC) 的时钟。它从 1970 年 1 月 1 日星期四 00:00:00 UTC 开始测量时间，包括闰秒。

将其与 的定义进行比较system_clock：

system_clock测量 Unix 时间（即，自 1970 年 1 月 1 日星期四 00:00:00 协调世界时 (UTC) 开始的时间，不包括闰秒）。

是否真的可以在同一个系统中拥有两者？例如，如果系统时钟通过 NTP 同步，则服务器决定现在是什么时间，这可能使用闰秒或不使用闰秒，但 C++ 库实现对此一无所知。或者，在引入闰秒时，该标准是否需要数据库？

考虑一台机器，它的时间在闰秒期间出现了正午到正午的线性拖尾。

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

例子：

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

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

• 中午开始涂抹，这意味着下午 1:30 系统的本地时钟已经比 TAI 和 UTC 落后几微秒。Epoch 时间戳应该是1483191000（正好 1 小时 31 分钟后），因为 Epoch 不考虑闰秒，所以它不再准确到 TAI/UTC
• 在 12pm UTC 增加一秒：11:59:60 pm，本地拖尾时钟应正常继续
• 直到 1 月 1 日中午，全球 UTC 和本地 UTC 再次同步，本地 Epoch 时钟现在落后全球 Epoch/TAI 整秒

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

我对日期时间算术的了解越多，我就越头疼。

时间有很多种：

• 民用时间
• 世界标准时间
• 泰
• UNIX 时间
• 系统时间
• 线程时间
• CPU时间

然后时钟可以跑得更快或更慢，或者向后或向前跳跃，因为

• 夏令时
• 跨时区移动
• 闰秒
• NTP同步
• 广义相对论

而如何处理这些又取决于：

• 操作系统
• 硬件
• 编程语言

所以请有人告诉我，对于我的具体用例，测量短间隔的最安全和最可靠的方法？这是我正在做的事情：

我正在用Python (3.7.x) 制作游戏，我需要跟踪某些事件发生后的时间。例如，玩家按住按钮多长时间，或者敌人发现玩家多长时间，或者关卡加载多长时间。时间刻度应该精确到毫秒（纳秒是多余的）。

以下是我想确保避免的情况：

• 你在深夜玩游戏。在您所在的时区，那天晚上，DST 凌晨 2 点的时钟向前移动了一个小时，因此分钟数为：1:58、1:59、2:00、3:01、3:02。游戏中的每个与时间相关的变量突然增加了一个小时——它认为你一直按住那个按钮一小时两秒，而不是仅仅 2 秒。灾难接踵而至。

• 相同，但 IERS 决定在当天的某个时间插入或减去闰秒。您播放过渡，所有时间变量都会增加或减少额外的秒数。灾难接踵而至。

• 您在火车或飞机上玩游戏，当您越过时区边界和/或国际日期变更线时，灾难随之而来。

• 游戏在某些硬件和操作系统上的上述情况下正常运行，但在其他情况下不能正常运行。即它在Linux 上中断但在Window 上不中断，反之亦然。

而且我不能真正为这些编写测试，因为有问题的事件很少出现。我需要在第一时间把它做好。那么，我需要使用什么与时间相关的功能呢？我知道有普通的 old time.time()，但也有一系列令人眼花缭乱的其他选择，比如

• time.clock()
• time.perf_counter()
• time.process_time()
• time.monotonic()
• 然后是上述所有内容的纳秒变体。

从阅读文档看来，这似乎是time.monotonic()我想要的。但是，如果阅读有关计时的所有细节教会了我什么，那就是这些东西从来都不是它们看起来的样子。曾几何时，我以为我知道什么是“秒”。现在我不太确定。

那么，如何确保我的游戏时钟正常工作？

所以我有一个 LocalDateTime 解析器，它接受一个日期作为字符串。我已经为它写了几个测试，例如检查闰年等等。

现在我想要一个 JUnit 测试来检查闰秒。我做了一些研究，发现 java.time(?) 可能是不可能的。到目前为止，我找到了一个合适的闰秒日期。

这是我迄今为止尝试过的：

虽然DateConvertUtils包含我上面提到的解析器和自定义DateTimeFormatter.

我感谢任何对正确方向的帮助。

当我发布此声明时：

我得到这个列表：

但是没有关于支持 DST、闰秒的信息。我可以从中选择该信息的表名是什么？

如果没有包含该信息的表格，您能否链接一些该信息的可靠来源？

我在 MySQL 8 的文档中找不到该信息。我发现的唯一内容是：时区社区包 阅读它使我得出结论，posix/时区没有闰秒结果，并且可能right/意味着它可能会right按exact时间返回，所以可能有闰秒。但是我不确定我的结论，我也不知道我们是否Europe/London会给出闰秒的结果，以及他们三个是否都支持 DST。

我将 Linux Debian 用于 MySQL 服务器和客户端。