Remember how panicked we all were about the Y2K crisis back in the year 2000? Everyone freaked out because computers only used two digits to represent a year in their internal clocks, so Jan. 1, 2000 would also be 1/1/00 – the same apparent date as Jan 1. 1900.
In 1999, this problem looked as if it might derail modern life, as computers reset themselves as if it were the beginning of the century and not the end.
Now there’s a new, even bigger global software coding fiasco looming: A huge amount of computer software could fail around the year 2038 because of issues with the way the code that runs them measures time.
Once again, just like in 1999/2000, every single piece of software and computer code on the planet must now be checked and updated again. That is not a trivial task.
In 2000, we bypassed the Y2K problem by recoding the software. All the software – a fantastically laborious retrospective global patch. Although Y2K was not a disaster, it was a massive disruption to the tech industry at the time. Virtually every company on the planet running any type of software had to locate their specific Y2K issue and hire someone to fix it. Ultimately, Y2K caused ordinary people very few problems – but that’s only because there was a huge expenditure of time and resources within the tech business.
The 2038 problem will affect software that uses what’s called a signed 32-bit integer for storing time. For those who aren’t well-versed in computer science, bits are how memory is stored; they are how computers save documents.
When a bunch of engineers developed the first UNIX computer operating system in the 1970s, they arbitrarily decided that time would be represented as a signed 32-bit integer (or number), and be measured as the number of milliseconds since 12:00:00 a.m. on January 1, 1970. (For instance, the value “919642718″ is 919,642,718 seconds past that date in the 1970s – or Sunday, February 21, 1999, at 19:18:38 ET.)
UNIX time coding has since been incorporated widely into any software or hardware system that needs to measure time.
This system makes a lot of sense when you need to see how much time has passed between two dates. The problem arises because 32 bit software can only measure a maximum value of 2,147,483,647 seconds. This is the biggest number you can represent using 32 bit system.
To understand this, consider that the biggest number you can represent with one digit is 9. The biggest number with two digits is 99. The number system we’re used to uses a base of 10. So two digits can represent all of the numbers up to 100, or (10 x 10)-1, which equals 99. And three digits can represent numbers up to 1000, or (10 x 10 x 10) -1 = 999.
The binary system that computers use works the same way, but with a binary base of two, instead of 10. So for a 32-bit system counting in binary base of two, the highest number it can represent is (2 to the power of 32) -1, which equals … 2,147,483,647.
On January 19, 2038 – 2,147,483,647 seconds after January 1, 1970 – these computer programs will exceed the maximum value of time expressable by a 32-bit system using a base 2 binary counting system, and any software that hasn’t been fixed will then wrap back around to zero, thinking that it’s 1970 again.
To learn more about this problem, we checked in with Jonathan Smith, a Computer and Information Science professor at the University of Pennsylvania.
According to Professor Smith, this is a real problem that will affect a specific subset of software that counts on a clock progressing positively.
“Most UNIX-based systems use a 32 bit clock that starts at the arbitrary date of 1/1/1970, so adding 68 years gives you a risk of overflow at 2038,” he explains. “Timers could stop working, scheduled reminders might not occur (e.g., calendar appointments), scheduled updates or backups might not occur, billing intervals might not be calculated correctly.”
Thankfully, though, the solution technically difficult. We just need to switch to higher bit values like 64 bits, which will give a higher maximum. In the last few years, more personal computers have made this shift, especially companies that have already needed to project time past 2038, like banks that need to deal with 30-year mortgages.
In reality, the 64-bit system just pushes off the problem to a later date when the new maximum is reached, but they do extend the maximum date to 292 billion years from now – which seems like a pretty good deal.
Apple claims that the iPhone 5S is the first 64-bit smartphone. But the 2038 problem applies to both hardware and software, so even if the 5S uses 64 bits, an alarm clock app on the phone needs to be updated as well. (If it’s using a 32-bit system in 2038 it will wake you up in 1970, so to speak.) So the issue more of a logistical problem than a technical one.
The problem does not seem too urgent – we have 24 years to fix it it! – but its scope is massive. To give you an idea of how slowly corporations can implement software updates, a majority of ATM cash machines were still running Windows XP, and thus vulnerable to hackers, until April of this year even though Microsoft discontinued the product in 2007.
And the Y2K fiasco suggests that the tech industry will, by and large, ignore the 2038 issue until it becomes too expensive not to – i.e. the very last minute.