Why the year 2038 is not just another normal year

Besides love and death, time is arguably one of the most-loved subjects by poets. Now, poets and the world of data and computing don’t traditionally go together. Where time (or at least the representation of time) is concerned, however, a healthy respect for it is due, because as the poets are often so good at explaining, time is indeed running out…

The year 2038 is our cut-off year where a digital representation of time will possibly run out. More specifically, on 19 January 2038 at 03:14:08 am UTC, systems using a signed 32-bit integer to keep track of time, will potentially not be able to do so beyond that second and jump back to the 13 December 1901 at 08:45:52 pm UTC. This is a massive problem for several reasons. If you have a VoIP system, for example, that does you billing automatically and you are set to receive your next billing details at the end of January 2038, but your system now thinks it is 1901, your billing will be a complete mess if you get it at all that month. More seriously, a system that controls pension payments suddenly thinks the year is 1901 it will have a bunch of people that, according to it, have not been born yet and do not need their pensions to be paid. Even more seriously, if you have a power station set to run automated tests on certain dates and times, the next one being in February 2038, and it also thinks it is suddenly the year 1901… the issue is obvious.

The question now is, why does this problem even exist and what is being done to fix it?

Y2K38

Some might recognise the Y2K above as the general notation for the year 2000 and the havoc that was expected more than twenty years ago when or time ticked over from 1999 to 2000. It caused programming pandemonium but never actually materialised as the industry recognised the problem early enough to do something about it. Y2K38 (the year 2038) is facing a remarkably similar situation.

Many programs and digital systems, especially older ones, use a signed 32-bit integer to keep track of time. 1 January 1970 at 00:00:00 UTC was chosen as the Unix Epoch (hence the name Epochalyps) – the start time for the system to start counting every second and so those systems have done for over 50 years. The 32 bits of ones and zeros only have so much space to keep counting, however, and when their space runs out, the problem barrels in.

At 03:14:08 am on 19 January 2013, the 32-bit integer will look as follows:

01111111111111111111111111111111

The zero shows that it is a positive number, and all the ones count to the over 2billion seconds since 1 January 1970. The second after that, however, will look as follows:

10000000000000000000000000000000

The 1 indicates that the number is negative, and all the zeros are the over 2billion second before 1 January 1970. In other words, the system has reset itself to 13 December 1901 at 08:45:52 pm.

What is being done to solve Y2K38?

Luckily for us, most modern systems work with a 64-bit system that doesn’t just double the time that system can keep track of, but exponentially increases it.

There is, unfortunately, no universal solution to this problem. Like the Y2K problem, experts in the field need to determine and analyse which systems will be affected and design solutions specifically for those systems. Compatibility layers can be added to the system and other systems use a 64-bit operating system on both 64- and 32-bit architectures but even then, they may still have issues in 2038.

The Y2K problem never came to fruition leading many to believe it was never as big an issue as it was made out to be, but that is just because the major problems were solved before they could pan out. We believe that the Y2K38 problem will follow the same route, but as of yet, there is much to be done to ensure this.