Note: This blog post was moved from an older blog
*Editor’s Note: This would have been a video, but I got lazy… Sorry :(.
On January 19, 2038, at exactly 03:14:07, many computers will probably fail. The reason has to do with the 2038 bug which I shall explain in the post below.
To start off with, let’s talk about how computers track time. Most computers track time through a counter hooked onto a hardware element that causes the counter to increment at certain intervals, usually seconds. The time is inferred from the time elapsed from a certain reference time or epoch. In the case of *nix systems, like Linux and macOS and some programming languages, this epoch started on January 1, 1970.
231-1 = 2,147,483,647
The issue with *nix systems is that they store the time difference from the epoch in a 32-bit signed integer. The biggest number a signed 32-bit integer can store is
2 147 483 647. Why not
2^32? The integer is signed, so the leading bit is reserved for the sign. Now, two odd billion sounds like a big number but you are mistaken. Being the Zimbabwean that I am having experience with numbers in the trillions, I can tell you that 2 billion isn’t enough.
I mean, it’s all fine and dandy until that two odd billion runs out. That time will be exactly 03:14:07 on the 19th of January 2038. Once that date is reached, the next second will bring things back all the way to 13 December 1901 at 20:45:45. Why does this happen? When the number is incremented after having all True 31 bits, the next value will cause the signed bit to increment, turning the number from a positive to a negative.
This sounds awful…Scratch that – this is awful! This bug has the potential to affect millions of systems. Desktop computers, phones, electronic assists in cars, avionics systems, industrial systems – anything using a signed 32-bit integer to store time. It’s not confined to hardware either. This bug could impact databases, file systems, medical software, military software among others.
Besides that incident with Paul Ryan’s economic forecasts, people have encountered some issues. AOL screwed up and some people couldn’t play video games. Also, some people have one more year (2018) to fix this bug lest their future calculations stop working. To be honest, I’m being a bit melodramatic. Knowing that this bug exists doesn’t necessarily predict that computers will catastrophically fail.
The last time we had this big of a scare based on time was during the Y2K bug craze where the issue had to do with storing only the last two digits of the year (so 2000 would actually be 1000). While they were warned about it 50 years in advance, they only started working on it in the last decade of the 1000’s, a bit like my essays and Paul Ryan’s healthcare bill. Thanks to programmers providing $300 billion in effort, they were able to mitigate disaster, although things did fail and they subsequently got fixed.
Now we know the problem and what it could do, how can we fix it? Well, the answer is surprisingly simple, but not easy. A good fix would be to move from 32-bits to 64-bit, giving us 293 billion years (about 22 universes) to think of something better. But, as I said, it’s simple, not easy. Any change is bound to break something.
time_t is a function in the C programming language responsible for storing time as a 32-bit signed integer on some computers. If
time_t was changed to an unsigned number, we would work with numbers into 2106, but dates before 1970 won’t work.
64-bit computers already use the 64-bit integer, although they can’t calculate past 32-bit for legacy issues. Some Linux kernel maintainers have spent years finding a fix. Bergman has a proposal, but only one fix has been committed. Clearly, this will take a while to sort out, but I trust that programmers will be able to think of something.