Because of the similarity in the way that GPS and TAI handle UTC leap seconds, the calendrical representation of GPS is always behind that of TAI by 19 seconds.įile_clock is the clock used by the filesystem library, and is what produces the chrono::time_point aliased by std::filesystem::file_time_type. Like TAI, every time a leap second is inserted into UTC, the calendrical representation of GPS and UTC diverge by another second. It measures seconds since the first Sunday of January, 1980 00:00:00 UTC. It doesn't have leap seconds, but every time a leap second is inserted into UTC, the calendrical representation of TAI and UTC diverge by another second. Tai_clock measures seconds since 00:00:00 and is offset 10s ahead of UTC at this date. This is mainly useful when you need to subtract two time_points across a leap second insertion point, and you absolutely need to count that inserted leap second (or a fraction thereof). Utc_clock is just like system_clock, except that it counts leap seconds. And new for C++20Ĭ++20 adds four more clocks to the library: And it can be very surprising if you use it without realizing that processor time is what you're measuring. This can be really useful if that is what you need to measure. That is, when your thread is not busy doing something, and the OS has parked it, measurements of std::clock will not reflect time increasing during that down time. Std::clock tracks processor time, as opposed to physical time. Otherwise std::time tracks UTC (excluding leap seconds), just like system_clock. So it is completely unusable for situations that require subsecond precision. Though not specified, std::time is typically restricted to a resolution of a second. So imho, it is best to just directly choose steady_clock or system_clock so that you know what you're getting. But some platforms alias to steady_clock and some to system_clock. High_resolution_clock is allowed to be a type alias for either steady_clock or system_clock, and in practice always is. And if you need to relate a timestamp to a human readable time such as a date/time on the civil calendar, system_clock is the only choice. But certainly hours or days qualifies as "long", and durations under a second don't. And system_clock is best for timing "long" times where "long" is very fuzzy. It also typically has nanosecond resolution, though that is not required. This boils down to the fact that steady_clock is best for timing short durations. But since it never gets adjusted, it may drift over time with respect to system_clock which is adjusted to keep in sync with UTC. It is great for timing short bits of code. But it will never be adjusted, especially not backwards. It may not keep perfect time (no clock does really). It has no relationship to any time standard. Unless abused by an administrator, system_clock does not jump by gross amounts, say due to daylight saving, or changing the computer's local time zone, since it always tracks UTC. It is actually possible (though not likely nor common) for timestamps from this clock to go backwards by tiny amounts. These adjustments are typically on the order of microseconds, but can be either forward or backwards in time. This is often done with a network service such as NTP. Every once in a while (maybe several times a day), it gets adjusted by small amounts, to keep it aligned with the correct time. System_clock is a clock that keeps time with UTC (excluding leap seconds).
0 Comments
Leave a Reply. |