Y2K was a pop culture phenomenon. Shows such as The Simpsons and South Park released episodes relating to this purported disastrous event. There was an air of uncertainty and fear, however, when January 1, 2000, came and went, it wasn’t an apocalyptic event. So what was the commotion about? The issue had to do with dates, specifically the way years were stored in computers. The year 1987 was stored as 87 and 1999 as 99, and so on. You can see the issue with the year 2000 as 1900 would be represented by the same two digits, 00. Through some extensive work, systems engineers were able to fix the issue, which helped lead to a non-apocalyptic January 1, 2000. However, a similar problem is expected in the year 2038.
On January 19, 2038, 32-bit Unix systems will experience time integer overflow. To understand this concept completely, I’ll have to go into some details. The system time on Unix 32-bit systems is represented by a signed 32-bit integer. The Unix Epoch or second zero started on January 1, 1970. Dates referring to before 1970 are negative numbers and those referring to after 1970 are positive numbers. The issue is that a signed 32-bit integer can only go from -2,147,483,648 to 2,147,483,647. On January 19th, 2038, the upper limit on seconds will be reached. Due to the way signed numbers are represented in binary, the integer will overflow and become negative. It’s unknown what exactly will happen to each affected system but rarely does corrupted system time lead to positive results.
So should we all panic for the end of days coming 2038? Most likely not. Modern computers and systems often use 64-bit architectures now, with a signed 64-bit integer to represent time. If you’re curious when that runs out, it’s over 292 billion years from now. That’s over twenty times longer than the universe has existed and I have a feeling we will be beyond 64-bit by then. If 64-bit has already replaced most 32-bit systems, then why even be concerned about it? The answer to that is legacy and embedded systems.
Legacy systems and embedded devices that are still running on 32-bit Unix systems have the potential to be affected by the 2038 problem. Many of these devices were developed for longevity and may be expected to be in service past 2038. There are a few possible solutions to this. The simplest involves replacing the hardware with a 64-bit system. Another involves rewinding system time and clock synchronization. Essentially, system time is rewound to a previous date, for example, the year 2000, and another resource on the machine keeps a count of seconds to add to the rewound time to get the correct time. Rewinding system time is a good way to gain extra years in order for the system to be replaced with a 64-bit machine.
A final key piece to solving this problem involves detection. In order to solve a problem, you need to know that there is a problem. While this may be obvious in some instances, there are sometimes “hidden” issues. A great example is the popular database MySQL. The timestamp field uses a 32-bit field for time and therefore is susceptible to integer overflow in 2038. There is an easy solution to this by using the DateTime field, which uses more space. Some old C libraries also used a 32-bit signed int for time, which may cause issues on machines that aren’t even Unix! Detection of the 2038 problem will be the topic of my graduate project because I believe it will be an important aspect of tackling the issue.
There is ample time to solve this issue and detect any possible affected systems. While I don’t believe this will be an apocalyptic event, there is the potential for some unknown surprises along with humanity’s dangerous trend towards procrastination (individuals were aware of the Y2K issue in 1979, yet no serious action was taken until 1997). Despite it all, I look forward to seeing all the work that goes into solving this problem so that January 19, 2038, will be another uneventful day. Then we’ll have 292 billion years to procrastinate until 64-bit time runs out!
Happy Snail Programming 