The year 2038 is still more than two decades away, but LWN.net editor and longtime Linux kernel chronicler Jon Corbet believes software developers should be thinking about that date now, particularly in the Linux world.

Corbet raised the issue at his annual "Kernel Report" talk at the Linux Foundation Collaboration Summit in Santa Rosa, California this week. "Time to start worrying," he said.

The issue is similar to the dreaded Y2K bug, in that a longstanding deficiency in the way some computers record time values is due to wreak havoc in all manner of software, this time in 2038.

This latest problem comes down to the "time_t" time codes used by Linux and other Unix-compatible operating systems. Because they were specified as 32-bit values – back in the early days of Unix, when 2038 was almost a century away – they're eventually going to run out of bits with which to tick off seconds. Specifically, that's going to happen at exactly 03:14:07 GMT on January 19, 2038.

So why worry now, when we still have decades to fix the problem?

Jon Corbet thinks the time to tackle 2038 is now

"The simple fact of the matter is that systems are being built and deployed now that will still be in service 23 years from now," Corbet said. "Linux-based systems are being put into cars, into building control systems, into power plants, and into who-knows-how-many other places where they will just simply sit there and do their job until time_t runs out of bits. And then they won't work anymore."

Once they're installed and forgotten, these systems will be very difficult to spot before the Year 2038 bug jumps up to bite them, Corbet said. What's more, many of them will be difficult if not impossible to patch – which is why developers should stop shipping them, ASAP.

But switching to longer time values isn't as easy as it sounds, because making such changes invariably breaks code that depends on the older specification.

In the case of the Linux kernel, while the core timekeeping code was updated to address the Year 2038 issue over the course of 2014, many routines in the outer layers of the kernel are still susceptible to the bug.

"For example, the ext3 file system will break," Corbet said. "I don't know if that's ever going to get fixed, or if we'll just hope nobody is using ext3 by then. Hopefully not too many people are using it even now."

Many system calls – the mechanisms by which applications talk to the kernel – will also need to be fixed, or applications, too, could break. And beyond the kernel itself, the various C libraries currently in use – such as the GNU C Library (glibc) that typically ships with Linux systems – will likewise need updating.

"There have been some conversations that I have seen with the C library developers, so things are getting thought about. But I don't know that there's anything resembling a serious plan at this point," Corbet said. "In terms of actually fixing applications that deal with this problem, well ... that isn't happening yet, as far as I can tell."

While it's far from being too late to address these issues, however, each year that developers produce software that doesn't take 2038 into account only compounds the problem.

"If we continue to distribute software that has this problem in it, we are setting up problems for the future, and we don't want to do that," Corbet said. "The time to fix it is now." ®