THE 2038 PROBLEM

There are plenty more integer overflow bugs out there, and one of the most prominent involves dates stored on Unix and Unix-like operating systems. While it’s fixed on most of the Unix-likes we use commonly, such as Android, macOS, and iOS (early versions of OS X are vulnerable, but the chances are they won’t still be in use in 2038), embedded Unix systems like those in factories, medical systems, airplanes, or cars might be still in use—it’s only 18 years, after all.

It’s also a problem with things like file systems and databases, which have been written with a Unix timestamp in mind.

The problem is this: susceptible systems treat dates as a number of seconds after January 1, 1970. This figure is stored as a 32-bit integer, and the largest possible value that can be stored is 2,147,483,647. This is a lot of seconds, but runs out at 3:10:07 AM on Tuesday, January 19, 2038. After this, it will be interpreted as a negative number, or 8:45:52 PM on Friday, December 13, 1901. It then counts up again, toward zero.

There’s no universal solution to this problem, beyond upgrading to a 64-bit OS or architecture.

Java, for example, uses 64-bit integers to count microseconds since January 1, 1970, and won’t run out of dates for almost 300 million years (it overflows at about 3:30 PM on a Sunday). By then, we might even have received our RTX 3080 cards.

Time and date storage problems are fairly common. Owners of Boeing 787 aircraft —we know you’re reading—should be aware that if you don’t switch your airplane off at least once every 51 days, you’ll get misleading data from it (including important things like altitude and airspeed). And there is, of course, a Year 10,000 problem too, linked to the year having five digits instead of four.

And Windows users should stop looking so smug: that OS’s date range runs out in the year 30,828— though that’s plenty of time for a patch there.