Ykhjuy

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 7.23.2.4 (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 __TIME__ and __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.

Furthermore, since 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.