【问题标题】:When is std::chrono epoch?std::chrono 时代是什么时候?
【发布时间】:2018-02-03 13:48:18
【问题描述】:

std::chrono::time_point::time_since_epoch() 返回一个duration,过去引用了一些time_point。什么时候是这样的time_point?它取决于 C++ 实现还是由 C++ 标准定义?还是将纪元设置为 1970 年 1 月 1 日 UTC 是事实上的标准?

【问题讨论】:

标签: c++ c++11 epoch chrono


【解决方案1】:

它既是 time_point 所指的特定 clock 的函数,也是 clock 的实现。该标准规定了三种不同的时钟:

  • system_clock
  • steady_clock
  • high_resolution_clock

而且标准没有指定这些时钟的纪元。

程序员(你)也可以编写他们自己的时钟,这可能会也可能不会指定一个纪元。

有一个事实上的(非官方的)标准,std::chrono::system_clock::time_point 的纪元与Unix Time 一致。这被定义为自 1970 年 1 月 1 日星期四 00:00:00 协调世界时 (UTC) 以来经过的持续时间,不包括闰秒。

Fwiw,here is a date/time library,它利用了这一事实标准。

其他两个标准指定的时钟没有事实上的标准。此外,high_resolution_clock 可以作为system_clocksteady_clock 的类型别名。

在 OS X 上,high_resolution_clocksteady_clock 的类型别名,steady_clock 是计算机启动后的纳秒计数(与 UTC 没有任何关系)。

更新

C++2a 规范草案现在说 system_clock

sys_time<Duration> 类型的对象测量自(和之前)以来的时间 1970-01-01 00:00:00 UTC 不包括闰秒。这个措施是 通常称为 Unix 时间。这项措施有利于 sys_time 和日历类型 (27.8) 之间的有效映射。 [例子sys_seconds{sys_days{1970y/January/1}}.time_since_epoch()0ssys_seconds{sys_days{2000y/January/1}}.time_since_epoch()946’684’800s,即10’957 * 86’400s。 —结束示例]

此外,C++2a 还引入了utc_clocktai_clockgps_clockfile_clock。这些时钟也有明确定义的纪元,因为可以clock_casttime_points 从一个时钟到另一个时钟,system_clock

file_clock 纪元将不可移植,但您仍然可以将其 time_points 与民用日历相关联。

utc_clock 类似于system_clock,只是它不忽略闰秒。例如:

#include <chrono>
#include <iostream>

int
main()
{
    using namespace std::chrono;
    auto s1 = sys_days{December/31/2016} + 23h + 59min + 59s;
    auto s2 = sys_days{January/1/2017};
    auto u1 = clock_cast<utc_clock>(s1);
    auto u2 = clock_cast<utc_clock>(s2);
    std::cout << s2 - s1 << '\n';
    std::cout << u2 - u1 << '\n';
}

输出:

1s
2s

更新

链接到现在指定的 (C++20) system_clock 纪元:http://eel.is/c++draft/time.clock.system#overview-1

system_­clock 类型的对象表示从 系统范围的实时时钟。 sys_­time&lt;Duration&gt; 类型的对象 测量自 1970-01-01 00:00:00 UTC 以来的时间,不包括闰秒。 这种度量通常称为Unix 时间。这项措施 促进sys_­time 和日历之间的有效映射 类型([time.cal])。 [ 例子: sys_­seconds{sys_­days{1970y/January/1}}.time_­since_­epoch()0ssys_­seconds{sys_­days{2000y/January/1}}.time_­since_­epoch()946'684'800s,也就是10'957 * 86'400s——结束示例 ]

【讨论】:

  • 对于未来的读者:您是否有官方文档的链接列表,可以检查这是否仍然正确?
  • 这里是所有的 C++ 论文:open-std.org/jtc1/sc22/wg21/docs/papers 在这些文档中将包含 C++ 标准的草案,其中包含 &lt;chrono&gt; 的官方规范。官方的 C++14 规范是 open-std.org/jtc1/sc22/wg21/prot/14882fdis/n4141.pdf,但它不是免费提供的。但是open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf 是之后的下一个草稿,应该足够接近。 C++17的当前草案是open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4618.pdf
  • 非常感谢,我应该更准确地说:我的意思是,如果有关于 std::chrono::system_clock 的不同标准库实现的实际行为的任何文档。这将避免编写特定于平台的单元测试来验证该行为的必要性。
  • 没有官方信息。这是一个做很多事情的提案,其中之一是标准化system_clock的时代:open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0355r1.html但这只是一个提案,不可能早于2020年生效。它成功的机会是可能低于 50%。我已经与 VS、gcc 和 clang 的当前维护者进行了交谈,并达成了非正式协议,即他们不会更改 system_clock 的时代。尽管 Stephan Lavavej 在这里宣布了其他情况:youtube.com/watch?v=P32hvk8b13M&t=54m21s
  • 再次感谢。现在我还记得为什么我首先担心system_clock:我看了你后续关于你的时区库的谈话,你重复了 Stephan 的声明,即 VC 计划改变时代。我很高兴听到这似乎不再摆在桌面上。
猜你喜欢
  • 1970-01-01
  • 2014-03-23
  • 2016-09-22
  • 2011-03-25
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多