3

我看了一下 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++ 库实现对此一无所知。或者,在引入闰秒时,该标准是否需要数据库?

4

2 回答 2

3

NTP 服务器为您提供 UTC(以 seconds-since-1900 格式)。当前时间,是当前时间。为了到达那里,有多少闰秒并不重要。

事情变得复杂的地方是添加了闰秒。NTP 将在此刻宣布这一点,并且各种操作系统在内部做各种事情来记录这一点,因为它们倾向于将时间存储为“自一个纪元以来的秒数”——Linux 和 Windows 不包括闰秒,因为这会使他们的时间戳渲染更加复杂(有多少闰秒?)并且他们无法处理。相反,他们只是在宣布的闰秒前后稍微减慢或加快时钟,因此他们并没有实际记录它,而是调整自己的秒数,以便将该计数作为时间戳呈现在以后会显得准确。

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

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

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

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

进一步阅读

于 2019-06-16T12:38:22.710 回答
2

我找到了这个关于 C++ 20 时间的工作草案,它似乎应该在公元 2020 年发布。它有一个关于 utc_clock的子页面,其中包括这个例子:

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'822s,即 10'957 * 86'400s + 22s。” 请注意,10,957 天大约是 30 年,因此 utc_clock 的值显然表示自 1970 年 1 月 1 日 UTC 以来的秒数,其中每个闰秒都会增加 utc_clock 的值。

由于这表示为转换,因此推断转换将调用闰秒表似乎是合理的,并且即使操作系统没有 UTC 和 TAI 之间区别的概念,也没有分钟的概念,也可以执行该转换其中包含 61 秒。

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

于 2019-06-16T16:23:01.383 回答