I took a look att cppreference.org (emphasis mine):
The clock
std::chrono::utc_clock
is a Clock that represents Coordinated Universal Time (UTC). It measures time since 00:00:00 UTC, Thursday, 1 January 1970, including leap seconds.
Comparing that to the definition of system_clock
:
system_clock
measures Unix Time (i.e., time since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, not counting leap seconds).
Is it actually possible to have both in the same system? For example, if the system clock is synchronized via NTP, then the server decides what time it is, and that could use leap seconds or not, but the C++ library implementation cannot know anything about that. Or, does the standard require a database over when a leap second was introduced?
NTP servers give you UTC (in a seconds-since-1900 format). The current time, is the current time. It doesn't really matter how many leap seconds there have been in order to get there.
Where things get complicated is when a leap second is added. NTP will announce this in the moment, and various operating systems do various things internally to record that, owing to their propensity to store time as "number of seconds since an epoch" — Linux and Windows don't include leap seconds in this, because it would make their timestamp rendering more complicated (how many leap seconds have there been?) and they can't be dealing with. Instead, they just slow or speed up the clock for a little while around the announced leap second, so rather than actually recording it they just adjust their own seconds-count so rendering that count as a timestamp will appear accurate later.
(What I don't know is how an OS will redetermine its not-really-but-sort-of-seconds count from an NTP transaction without knowing how many leap seconds to deduct; edits welcomed.)
system_clock
gives you this seconds count, which (on mainstream platforms) just comes straight from the OS (e.g. time()
).
utc_clock
gives you a similar seconds count, but one that is "real". On such mainstream platforms this will necessarily have to be the system_clock
with leap seconds added after-the-fact. This historical data comes from the system too, indeed some kind of database (though the exact source is up to the implementation).
In conclusion, the data sources for the two clocks are (slightly) different, so there is no question of whether they can co-exist on the same system. But, the system_clock
probably comes directly from your operating system, in a way that the utc_clock
probably doesn't.
utc_clock
feature and its friends: https://howardhinnant.github.io/date/d0355r4.html