问题描述
在打印日志时，我希望每个消息都有一个时间戳，以测量自程序启动以来的时间。最好以纳秒为单位，尽管毫秒也可以：
( 110 ns) Some log line
( 1220 ns) Another log line
( 2431 ns) Now for some computation...
(10357 ns) Error!
据我了解，C ++ chrono库中有三个不同的时钟，还有两个C风格的时钟：
- std :: chrono :: high_resolution_clock
- std :: chrono :: system_clock
- std :: chrono :: steady_clock
- std :: time
- std :: clock
每种上述任务的利弊是什么？
解决方法
system_clock是与UTC保持时间（leap秒除外）的时钟。偶尔（可能一天几次）会对其进行少量调整，以使其与正确的时间保持一致。这通常是通过网络服务（例如NTP）来完成的。这些调整通常约为微秒，但时间上可以向前或向后。实际上，此时钟的时间戳可能会（虽然不太可能，也不常见）向后倒退一小段时间。除非被管理员滥用，否则system_clock不会跳总值，例如由于夏令时或更改计算机的本地时区，因为它始终跟踪UTC。
steady_clock就像秒表。它与任何时间标准都没有关系。它一直在滴答作响。它可能无法保持完美的时间（没有时钟可以做到）。但是它永远不会被调整，尤其是不会向后调整。这对定时短代码很有用。但是由于从未调整过，因此它可能会相对于system_clock随时间漂移，而调整后的steady_clock与UTC保持同步。
这归结为以下事实：system_clock最适合计时较短的时间。尽管这不是必需的，但通常也具有纳秒分辨率。 system_clock最适合计时“长”非常模糊的“长”时间。但是可以肯定的是，数小时或数天可以视为“长时间”，而持续时间不到一秒则没有。而且，如果您需要将时间戳与诸如民用日历上的日期/时间之类的人类可读时间相关联，则steady_clock是唯一的选择。
high_resolution_clock可以用作system_clock或steady_clock的类型别名，实际上始终是。但是某些平台的别名为system_clock，另一些平台的别名为steady_clock。因此，恕我直言，最好直接选择system_clock或std::time，以使您知道自己要得到什么。
尽管未指定，但是std::time通常限于一秒的分辨率。因此，对于要求亚秒级精度的情况是完全不可用的。否则，system_clock会跟踪UTC（不包括leap秒），就像std::clock一样。
std::clock跟踪处理器时间，而不是物理时间。也就是说，当您的线程不忙于做某事并且操作系统已将其停放时，<chrono>的测量值将不会反映该停机时间内时间的增加。如果这是您需要测量的，那么这将非常有用。如果您在没有意识到处理器时间就是您要测量的情况下使用它，那将非常令人惊讶。
C ++ 20的新功能
C ++ 20向system_clock库中增加了四个时钟：
utc_clock与time_point相似，只是它计算leap秒。当您需要在a秒插入点上减去两个filesystem，并且您绝对需要计算所插入的or秒（或其一部分）时，这非常有用。
tai_clock自1958-01-01 00:00:00起测量秒数，并且在该日期比UTC提前10秒。它没有leap秒，但每次在UTC中插入a秒时，TAI和UTC的日历表示就会再相差一秒钟。
gps_clock为GPS时间系统建模。它测量的时间是自世界标准时间1980年1月的第一个星期日00:00:00。像TAI一样，每将a秒插入UTC，GPS和UTC的日历表示就会相差一秒。由于GPS和TAI处理UTC跳秒的方式相似，因此GPS的日历表示总是落后于TAI 19秒。
file_clock是chrono::time_point库使用的时钟，是产生std::filesystem::file_time_type别名的clock_cast的原因。
一个人可以使用C ++ 20中名为time_point的新名称转换来在system_clock，utc_clock，tai_clock，gps_clock， file_clock和auto tp = clock_cast<system_clock>(last_write_time("some_path/some_file.xxx"));
。例如：
tp system_clock的类型是基于time_point的{{1}}，其类型{precision}与duration相同。