Back2038 – The End of Time (UNIX)
The set date for when time will end is January 19th, 2038 at precisely 03:14:07 UTC. It is not a hoax or made up aluminum-foil-hat-wearing-hippy stuff. This is real, and it will happen. Nothing we can do about it so you better start getting ready for it sooner than later.
The Story
Now that I have everyone’s attention I want to give you some extra information on this. The “End of time” I am referring to is in regards to UNIX. During the early 1970’s computers were starting to become more and more popular, and a system was needed to act as a clock and keep time. And so, a counter was implemented increment up from zero. Initially the counter measured time in 1/60th of a second intervals. Since the systems were 32-bit, the maximum amount of time that could be represented was 828.5 days. There is a little bit of math involved which proves the previous statement, but since I won’t go through it here, you will have to take my word for it. The time this counter was set to start from was 01/01/1971 and would have expired not all that long from that. That was not a very good design as you can imagine.
Because the systems needed to keep time for more than 828.5 days, a new way to count time needed to be implemented. The ingenious solution was to use a time interval of 1 second instead of 1/60th of a second. With 1 second intervals, a 32-bit counter could now count for about 136 years. (828.5 days times 60 will give you ~136 years). Along with the time span improvement, the start of the counter was changed to start from an even 01/01/1970 instead of the previous 01/01/1971. And thus, January 1st, 1970 at 0:00:00 UTC is considered the Epoch of UNIX the “zero” time.
The Problem
So now that we got a little bit of info on how UNIX time works, let’s get to the core of the issue. The problem at hand is often referred to as Year 2038 Problem, Y2K38, 2038 Bug, End of UNIX time, etc. Because the above mentioned way that UNIX keeps time, we are basically waiting for a timer to reach its maximum. Here can use the good ol’ cliché “Not if, but when!”
It turns out that the counter expires at exactly January 19th, 2038 at precisely 03:14:07 UTC. But wait a minute, if the starting time is 1970 and the 32-bit counter can count for 136 years, wouldn’t that mean that we have until the year 2106? Well no. And the reason for that is some very simple math. 136 years divided by 2 equals 68 years. So 1970 + 68 = 2038. Why are we dividing by two? The answer is that we need to be able to tell time in the past – or in other words, computers should be able to recognize time pre 1970. Therefore, when we divided 136 years by 2, we get 68 years after 1970, and 68 years before 1970. Our effective clock range now becomes 12/13/1901 to 1/19/2038, which is 136 years.
So what will happen when we reach the year 2038? Well, similar to how your clock works, we will start counting from the beginning again. On January 19th, 2038 at precisely 03:14:07 UTC, instead of the clock going to 03:14:08 UTC, it will overflow and go to 20:45:52 UTC of December 13th, 1901.
Who will be affected and how?
Since we are not at that point in time yet, no one can guarantee what exactly will happen, but I am certain it will not be a happy day for 32-bit systems. Anyone who uses a 32-bit signed integer to keep track of time is in trouble. Currently for example, a lot of computers, most of the smartphones, GPS devices, electronics in cars, and many more devices use the 32-bit architecture. In addition to the physical processors, 32-bit applications (that keep time) will also be inevitably affected even if they run on a 64-bit platform. The way these devices and applications will react will vary. Some will just show that it’s the year 1901, because it’s not possible for them to display a time larger than 03:14:07 UTC of January 19th, 2038. Other will suffer more serious consequences and crash. Whatever the outcome may be, it will not be good.
The Solution
There is a way to mitigate this problem. The simplest and most obvious solution would be to transition everyone over to the 64-bit architecture. It is important to note here that using the 64-bit will not completely fix the issue at hand, but delay it instead. That delay however is rather significant, and will extend the UNIX time by 292 billion more years. That’s not a typo, 292 billion with a “b”. By then I’m sure we would figure something else. For now however, 64-bit is the fix of the Y2K38 problem.
___________________________________________________________________________________________________________________________________________________________________
Peter Yordanov, Signing Out.
