The 2038 problem: Millennium Bug 2

Some of the greatest movies of all time have been sequels; Aliens, Terminator 2, Godfather 2 and Bill & Ted’s Bogus adventure were all better than the original. Could the same be true of the next big computer bug too? Well, it just might and it’s coming to a computer system near you soon.

Those of us that worked through the millennium remember that planes did not fall out of the sky, nuclear missiles didn’t launch themselves and elevators didn’t get stuck but at the time some people were painting this as a real possibility. Leonard Nimoy even made an hour-long documentary called the Y2K Family Survival Guide (which you can watch here) where you were advised to hoard medicines, water, food and cleaning products. There were a few minor issues such as a man being charged $91,000 for renting the General’s Daughter as the system assumed it was 100 years overdue and the Ecole centrale de Nantes sign incorrectly displaying the year, but the planning, work and vast expense (the US spent $100 billion) caused it to pass relatively smoothly.  The Year 2038 issue has not been as widely publicized (as yet) and as a result there is scope for some issues to fall through the cracks.

What is the 2038 problem?

The issue this time is not about the use of the century in the date as with the millennium bug but instead it concerns the way the date is stored. In binary the biggest positive number that will fit in 32 bits is 01111111111111111111111111111111 (or 2,147,483,647). This is an issue because computers store the time as the number of seconds since 1 January 1970 as a signed (positive or negative) 32-bit binary integer. When the value reaches 2,147,483,647 on 19th January 2038 at 3:14:07 the date and time will suffer an integer overflow and start storing the system as a negative number. The time shown will now be 20:45:52 on Friday, 13 December 1901 (i.e., 2,147,483,648 seconds before 1 January 1970) and the computer will start to count up towards zero, and then up through the positive integers again.

There was a taste of the things to come in 2014 when Gangnam Style broke YouTube’s view count which was using a 32-bit integer broke for a similar reason forcing YouTube to upgrade.

The year 2038 problem has also been called the Unix millennium bug because of the types of systems it will affect but it’s not quite that simple as it has the scope to be far more disruptive than that. Let’s look at some of the potential issues.

Embedded Systems

An embedded system is a computer system that has a dedicated function and is usually self-contained.  Many of these systems now use 64-bit dates and so there is no issue, but some systems still have the problem. For example, in cars embedded systems such as anti-lock braking system (ABS), electronic stability control (ESC/ESP), traction control (TCS) and automatic four-wheel drive may still be affected and in aircraft inertial guidance systems and GPS receivers may still have the issue. Although this sounds alarming this does not mean they will fail in 2038 as they don’t all rely on the date to function but clearly there is an issue. Similarly, some mobile/cell phones which need an accurate time and date often use UNIX-like operating systems. For example, some devices running 32-bit Android have been shown to crash if you change the date to 19th January 2038 at 3:14:07 (Disclaimer: if you try this it its at your own risk!)

Unix/Linux

Many of the newer Linux operating systems are now only available as 64-bit versions but older 32-bit Linux systems will still have an issue. To test this, I installed a 32-bit version of Debian that is still available for download and ran this simple perl test script (which I called year2038.pl).

use POSIX;
$ENV{'TZ'} = "GMT";
for ($t =2147483641; $t < 2147483651; $t++){
     print ctime($t);
}

As you can see when it reaches January the 19th in the year 2038 it fails at 03:14:07.

$ perl year2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

I tested the same script on a modern Mac Book running Big Sur (MacOS 11.2.1) and it works as expected but all versions before OS X 10.6 Snow Leopard will have the year 2038 problem.

% perl year2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

Windows

Microsoft has offered a 64-bit version of Windows since Windows XP Professional 64-bit was released in 2005. Microsoft also made changes in their Visual Studio C compilers to fix the problem which means that if your applications are compiled with Visual Studio 8 or later for the 64-bit architecture, the 2038 problem is fixed by default (Visual Studio 2003 contained __time64_t function but it had to be specifically used or the 32-bit version would still be used).

MySQL

Many web sites use WordPress and MySQL. MySQL has been shown to have an issue with the 2038 problem in that the database’s built-in functions like TIMESTAMP will return 0 after 03:14:07 UTC on 19 January 2038. This can be fixed by using DATETIME rather than TIMESTAMP but if a table has already been created it will need to be modified. In reality most sites that use MySQL will have been upgraded by 2038 but there is a small chance some may fail.

C Programming

Any program written in C/C++ could suffer from the Year 2038 problem. This is because most C programs use a standard time library that provides a number of functions for converting, displaying and calculating time values (usually via a variable of type time_t which was a 32-bit signed integer on 32-bit systems, and 64-bit signed integer on 64-bit systems). However, if a programmer writing code on a 64-bit platform explicitly casts a variable of type time_t to another variable which happens to be a 32-bit signed integer they will still have the issue. There is also a problem if you change the definition of the time_t data type without understanding how the code interoperates with other programs that has not been changed or data that has already been stored. For example, if you change time_t to an unsigned 32-bit integer, which would extend the range to 2106 but will have an issue manipulating date/time data previously stored using dates prior to 1970, as these are represented by negative numbers.

What is actually going to happen?

If we fast forward to the 19th January 2038 at 3:14:07 what will actually transpire? Almost all modern processors are now 64-bit systems running 64-bit software and so these systems will not suffer the problem.  Of those that aren’t fixed many more will be upgraded in the next decade. Additionally, many issues that are going to happen will occur long before time as if they store future dates that stretch beyond 2038 they will need to be fixed as and when the issues are found. Many web servers are currently 32-bit Linux systems, but 17 years is a long time for a web server to remain static and so my guess would be that many of these will also be upgraded.

The biggest issue may be embedded systems that are difficult to upgrade. They are used in many transportation systems such as stability control systems or ABS brakes in cars.  Some of these systems are in infrastructure such as power stations and may be more difficult to fix but hopefully the time remaining will be enough to plan these changes. Even so not all these embedded systems rely on precise dates. Time will tell whether this will be bigger issue than the Millennium bug or receive the same publicity but hopefully over the next decade companies will start to test their systems and check what needs to be changed and we won’t need the successor to Leonard Nimoy making videos warning of impending disaster.

Visits: 1761