Excerpted from the cppref:
Implementations in which
std::time_tis a 32-bit signed integer (many historical implementations) fail in the year 2038.
However, the documentation doesn't say how to detect whether the current implementation is 2038-safe. So, my question is:
Is it guaranteed to be 2038-safe if sizeof(std::time_t) == sizeof(std::uint64_t) in C++?
Practically speaking yes. In all modern implementations in major OSes
time_tis the number of seconds since POSIX epoch, so iftime_tis larger thanint32_tthen it's immune to the y2038 problemYou can also check if
__USE_TIME_BITS64is defined in 32-bit Linux and if_USE_32BIT_TIME_Tis not defined in 32-bit Windows to know if it's 2038-safeHowever regarding the C++ standard, things aren't as simple.
time_tin C++ is defined in<ctime>which has the same content as<time.h>in C standard. And in Ctime_tisn't defined to have any formatSo it's permitted for some implementation to have for example
doubleastime_tand store picoseconds from 1/1 year 16383 BCE, or even a 64-bit integer with only 32 value bits and 32 padding bits. That may be one of the reasonsdifftime()returns a doubleTo check y2038 issue portably at run time you can use
mktime