In a brief post, veteran sysadmin Rachel Kroll notes what happens when you set your Unix (Linux, BSD, OSX, and other systems that conform to the POSIX standard) to the year 2038. An otherwise unremarkable year, this is when legacy systems (the ones veteran sysadmins have to deal with) may have a significant problem with the way Unix has been counting microseconds since 1 January 1970.
On a specific date and time in 2038, the old-world model of time in 32 bits as a positive integer value ‘wraps around’ (when an integer value is too big for the container assigned in the computer) and returns nonsensical results. In the case of a 2038 disaster, like Y2K, this means fields that record time might suddenly announce times from 1 January 1970.
Except that isn’t quite what happens. Here’s why.
Rachel is very clear — to force a wraparound like what was feared with Y2K, systems have to be running in the very old-school 32-bit number model. Perhaps this could happen in a legacy situation where unmodified code has been running continuously on old hardware.
So, for most things, this problem simply doesn’t apply. Phones, Raspberry-Pi-based systems at home, smart TVs and fridges are by now (and by 2038) going to be running 64-bit CPUs with 64-bit clean design and won’t fall prey to this problem.
It’s still possible to encounter another problem, which is how the system itself copes when parts of the software model are 32 bits and parts are 64 bits. It is possible for a special Unix systems model of error coding to return a non-zero value. Zero in Unix and C denotes a ‘valid’ return from many tasks and a non-zero return means ‘something unusual happened’. This is, by far, the most likely response from modern systems, and it doesn’t mean that suddenly the entire world drops back to the flared jeans and cheesecloth shirts of the ’70s. Instead, some systems report errors. Some will report errors and quit and some silently quit.
The world, however, is a very big and strange place. There will be systems that either run on very dusty hardware or more likely on virtually dusty un-upgraded virtualized systems, which are running old operating systems and are running in the 32-bit domain. Most big enough companies wind up having this kind of dependency. It drives the saying ‘legacy code is something you’re too scared to change’ as well as a debate about the nature of investment in working technology, such as ‘technical debt’.
Rachel explores the visible states in a handy virtual system for one library dependency (glibc), but the Y2038 problem is not something to entirely laugh away. Remember: Y2K wasn’t a massive problem because people thought about it, not because ‘nothing happened’. The specific system component Rachel looked at is going to be fixed, and she notes that the BSD operating system family (NetBSD, OpenBSD) has already addressed it because all fixes in this space are about exposing incompatible system dependencies and fixing them.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
“the way Unix has been counting microseconds since 1 January 1970.
On a specific date and time in 2038, the old-world model of time in 32 bits as a positive integer value ‘wraps around’ (when an integer value is too big for the container assigned in the computer) and returns nonsensical results. In the case of a 2038 disaster, like Y2K, this means fields that record time might suddenly announce times from 1 January 1970.”
Well that’s wrong to start with:
1) 32-bit unix epoch time counts *seconds*, not *micro*seconds (no, we’re not going to squint and say “well, a second is 1000ms”, this is about precision).
2) Given the whole Y2038 issue is due to that 32-bit integer being **signed**, the wrap around wouldn’t be to 1st Jan 1970, it would be to … Fri 13 Dec 20:45:52 GMT 1901 (from `date -d @$(echo -2^31 | bc)` ). Yes, in the example in the blog post a clock_gettime64() call returns 0, rather than wrapping to negative, but other uses of `time_t` *will* wrap to negative.