Many of us have either heard of or remember the “Y2k” bug, a software issue in the 1990’s where certain systems were likely to break on January 1, 2000 when date and times would need to rollover to a year ending in 00. Many programmers and software engineers worked on resolving this issue as the nineties drew to a close, and were able to fix most bugs early on to avoid any catastrophes so that our computers and machines could live happily ever after.
Yet another technical quirk which poses a threat to older systems looms on the horizon – 03:14:07 UTC, January 19, 2038.
What is the Year 2038 Problem?
It all starts with how 32-bit UNIX systems keep track of time. These types of systems essentially keep track of time by counting how many seconds have passed since January 1, 1970, often referred to as “the epoch”. When a computer figures out what the time/day/year is, it is storing a single number which represents how long ago January 1, 1970 was in seconds.
Why January 19, 2038?
Consider this method of timekeeping to be like a pitch counter.
To a computer, January 1, 1970 is “0000” like in this picture. Now, as an example, let’s say that you use your pitch counter to keep track of what month it is, so after thirteen months have passed you’d look at your counter and see “0013”. After one hundred and sixty two months, you see “0162” and so on.
Now, say you keep using your counter for months and months and months, and eventually you’ll reach a point where 9999 months have passed. But when you click your counter to go to month 10,000 you end up back at “0000”.
Why is the computer running out of digits?
There is one piece missing from the pitch counter analogy, and that is negative numbers, but we’ll get to that in a moment.
32-bit UNIX systems store this time variable in a 32-bit signed integer. This looks like a big string of ones and zeroes which is 32 characters long, e.g. “01001011011101011001011010001100”.
This is a certain number of seconds represented in binary. In binary, you can represent (2^n) – 1 numbers where “n” is the number of digits you have. So a binary number three digits long could represent up to (2^3) – 1, which is seven.
Because the number a computer uses to keep track of time is 32 bits, or “digits” long, it would be able to represent (2^32) – 1 seconds since 1970. However, because it is “signed” the first digit is basically used as a plus or minus symbol to designate whether it’s a negative or positive number. So it can actually represent any number from “positive (2^31) – 1″ down to “negative (2^31) – 1″.
This means the biggest number of seconds it can hold with a 32 bit signed integer is (2^31) – 1 seconds, which as a whole number is 2,147,483,647 seconds.
What, then, is “January 1, 1970” plus “2,147,483,647 seconds”?
Exactly 03:14:07, January 19, 2038.
Why can’t we just add more digits?
Like a pitch counter, the number of digits it is able to hold is constrained by how it’s built physically. The CPU and operating system aren’t designed to be able to handle a further date than January 19, 2038.
Newer systems use 64 bits for keeping track of data, which is quite larger than what you can represent with 32 bits. But many systems still using these 32 bit time stamps will encounter problems when 2038 rolls around if they haven’t been switched over to newer systems or upgraded.
Why would anyone still be using these systems 23 years from now?
There are tons of programs and systems which are decades old at this point and are still in use today, and technical bugs so far into the future often weren’t a concern when these programs were originally developed. But now any system which relies on a 32-bit UNIX time stamp such as a database, file system, factory machinery or even file formats will need to be switched over to a 2038 compliant system within the next twenty three years.
That can seem a long way off with plenty of preparation time, especially in a field like technology where everything is constantly evolving, but for a government or company which doesn’t have the funds to rebuild the code used in all the public transit systems or in a hard to access location like a satellite or in a thirty year old database, it will probably be a while before the pressure is on to switch over everything still in use to something new.
Sources:
https://en.wikipedia.org/wiki/Year_2038_problem
http://www.timeanddate.com/calendar/monthly.html?year=2038&month=1&country=1