Some C++ implementations (for instance, battery-powered embedded devices) may have no use or no way for tracking the current date and time.
The C standard specifically allows for such implementations. To quote from ISO/IEC 9899:1999 126.96.36.199 (emphasis mine):
The time function returns the implementation’s best approximation to the current calendar time. The value (time_t)(-1) is returned if the calendar time is not available.
C++11 introduced the
chrono library and the
std::chrono::system_clock::now() function for getting the wall clock time from the system-wide realtime clock. The function is declared as
noexcept, so it cannot throw any exception to indicate unavailability nor does it allow returning any special value (like
-1 in the case of C).
But with C++11, C++14 and C++17 there was still a loophole. The standard didn't specify the clock's epoch, so a conforming implementation could set the epoch to the point in time when it was powered on (or the program was started) and still satisfy the requirements of the standard.
The current draft of C++20 will close that loophole and require
system_clock to use Unix time. In other words, a C++ implementation that doesn't know the current time is non-conforming.
Is this an oversight by the standards committee? How can a conforming C++ implementation indicate that it doesn't know the current date and time?
(Note that in other parts of the standard this problem is solved. For instance, an implementation may set the
__DATE__ macros to an implementation-defined value if the real time and date is not available.)
There is a distinction to be made between knowing the time, and knowing the correct time.
If such a device is turned on, it may freely assume that its CPU cycle counter (or whatever powers
steady_clock) represents the number of cycles since UNIX time. That is, it can assume that it was powered on at the moment of the UNIX epoch. That would be a valid implementation of
system_clock. That time will likely not be correct in some absolute sense, but it will be a conforming C++20 implementation.
The standard simply requires
system_clock's epoch to be UNIX time (or more specifically, we can all assume that it is UNIX time). That doesn't mean the tick count retrieved for the clock is guaranteed to be the globally accurate current time. After all, the user can technically change the current time, which is meant to be reflected in
system_clock (which is why it is not required to be a steady clock).
As such, you could never assume that
system_clock accurately represented the current time; it only represents what the operating environment thinks is the current time. So there is no way for
chrono to explain that the current time is or is not "correct" in some sense.
system_clock is basically meant to provide whatever is the closest to the correct time-of-day that the system can provide or understand. If the best the system can do is to assume that the device was turned on at the UNIX epoch, then that's what you get.
system_clock (and all of
<chrono> for that matter) is not on the list of freestanding requirements, C++ implementations for such devices could be freestanding implementations. And therefore they choose not to implement
system_clock (or all of
<chrono>) at all.