Twenty years later, the Y2K bug is making a comeback Watch Now

On 03:14:08 Greenwich Mean Time (GMT, aka Coordinated Universal Time) January 19, 2038 (that's a Tuesday), the world ends. Well, not in the biblical Book of Revelations sense. But, what will happen is the value for time in 32-bit based Unix-based operating systems, like Linux and older versions of macOS, runs out of numbers and starts counting time with negative numbers. That's not good. We can expect 32-bit computers running these operating systems to have fits. Fortunately, Linux's developers already had a fix ready to go.

The problem starts with how Unix tells time. Unix, and its relations -- Linux, macOS, and other POSIX-compatible operating systems -- date the beginning of time from the Epoch: 00:00:00 GMT on January 1, 1970. The Unix family measures time by the number of seconds since the Epoch.

So far, so good. But, since Unix and family started out as 32-bit operating systems, time's value is kept as a single signed 32-bit integer number. Those are a lot of seconds, but just like the last century's Y2K bug, it's not enough.

Linux developers have seen this coming for decades. So, Linux kernel developer Arnd Bergmann and others have been working on a repair. These corrections are now in the forthcoming Linux 5.6 kernel. Bergmann explained, "Linux-5.6, or my backport of the patches to 5.4, should be the first release that can serve as a base for a 32-bit system designed to run beyond year 2038."

There are some caveats:

All user space must be compiled with a 64-bit time_t, which will be supported in the coming musl-1.2 and glibc-2.32 releases, along with installed kernel headers from Linux-5.6 or higher.

Applications that use the system call interfaces directly need to be ported to use the time64 syscalls added in Linux-5.1 in place of the existing system calls.

Applications that use a private copy of kernel uapi header files or their contents may need to update to the Linux-5.6 version.

A few remaining interfaces cannot be changed to pass a 64-bit time_t in a compatible way, so they must be configured to use CLOCK_MONOTONIC times.

All Epoch problems present on 64-bit machines also apply to 32-bit machines. In particular this affects file systems with on-disk timestamps using signed 32-bit seconds: ext4 with ext3-style small inodes, ext2, xfs (to be fixed soon) and ufs.

In short, there's a lot of clean-up work to be done even after the core problem has been fixed.

MacOS has been moving away from 32-bit software for over a decade. But, tt was only in the late 2019 release of macOS Catalina, that Apple gave 32-bit apps the boot.

Now, you may be wondering -- since we're all running 64-bit computers these days -- why is this even an issue. Well, it's like this. First, many embedded systems and Internet of Things (IoT) devices are still running 32-bit operating systems. Indeed, by 2038, there will probably still be new 32-bit devices arriving in the market.

We also know, thanks to the Y2K bug popping up again in 2020, that systems you might assume will be dumped into landfills in 18-years will still be alive and well -- and badly misbehaving come the Epoch.

But look at this way: After we fix this, we won't have to worry about 64-bit Linux running out of seconds until 15:30:08 GMT Sunday, December 4, 29,227,702,659. Personally, I'm not going to worry about that one.

Related Stories: