闰秒和std：：Leap

Question

我看了一下att cppreference.org (强调我的)：

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

与system_clock定义的比较

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

实际上，在同一个系统中有可能做到这两种情况吗？例如，如果系统时钟是通过NTP同步的，那么服务器就决定它是什么时间，这可以使用闰秒，但是C++库实现不能知道这一点。或者，当引入闰秒时，该标准是否需要一个数据库？

Answer 1

NTP服务器为您提供UTC (秒-自1900年格式)。现在的时间，就是现在的时间。为了达到这个目标，有多少个闰秒并不重要。

事情变得复杂的地方是增加了闰秒。NTP将在此刻宣布这一点，不同的操作系统会在内部做各种事情来记录这一点，因为它们倾向于将时间存储为“自一个时代以来的秒数”-- Linux和Windows中不包括闰秒，因为这会使它们的时间戳渲染变得更加复杂(有多少个闰秒？)他们不可能是在处理。相反，他们只是在宣布的闰秒前后放慢或加快了一小段时间，所以他们不是实际记录它，而是调整它们自己的秒数，这样作为时间戳的计数就会在稍后出现准确。

(我不知道的是，操作系统将如何在不知道要减去多少闰秒的情况下，从NTP事务中重新确定它的非真正但排序的秒数；编辑是受欢迎的。)

system_clock给出了这个秒数，它(在主流平台上)直接来自操作系统(例如time())。

utc_clock给出了一个类似的秒计数，但一个是“真实的”。在这样的主流平台上，这必须是system_clock，并在事实之后添加闰秒。这些历史数据也来自系统，实际上是某种数据库 (尽管确切的源取决于实现)。

总之，这两个时钟的数据源(略有不同)，因此它们是否能在同一个系统上共存是不存在的问题。但是，system_clock可能直接来自您的操作系统，而utc_clock可能不是这样做的。

进一步阅读

• NTP和闰秒：https://www.meinbergglobal.com/english/info/leap-second.htm#os
• 新的utc_clock特性及其朋友：https://howardhinnant.github.io/date/d0355r4.html

Answer 2

我找到了这份关于时间的工作草案为C++ 20，它似乎是在公元2020年推出。它有一个钟，其中包括以下示例：

clock_­cast<utc_­clock>(sys_­seconds{sys_­days{1970y/January/1}}).time_­since_­epoch() is 0s.
clock_­cast<utc_­clock>(sys_­seconds{sys_­days{2000y/January/1}}).time_­since_­epoch()

最后值为946‘684’822 s，即10'957 *86‘400 s+22 s。注意，10,957天大约是30年，因此utc_clock的值显然表示自1970年1月1日世界协调时以来的秒数，其中每一次闰秒都会增加utc_clock的值。

由于这是一种转换，因此似乎有理由推断转换将调用一个闰秒表，即使操作系统没有UTC和TAI之间的区别，也没有包含61秒的一分钟的概念也可以执行。

我必须承认，与C++相比，我对时间更感兴趣，并且近20年来没有编写过严肃的C++代码。