{"id":69166,"date":"2014-05-29T12:26:00","date_gmt":"2014-05-29T16:26:00","guid":{"rendered":"http:\/\/rbachnet.wwwmi3-ss40.a2hosted.com\/index.php\/"},"modified":"2022-08-19T15:37:05","modified_gmt":"2022-08-19T19:37:05","slug":"70s-glitch-could-hit-every-computer-on-the-planet","status":"publish","type":"post","link":"https:\/\/rbach.net\/index.php\/70s-glitch-could-hit-every-computer-on-the-planet\/","title":{"rendered":"70s Glitch Could Hit Every Computer On Earth"},"content":{"rendered":"

\"70s<\/a>Rebecca Borison<\/a> at the BusinessInsider<\/em><\/a> asks<\/a> who remembers the 1999 panic about the Y2K crisis<\/strong>. In 1999, Y2K looked as if it might derail modern life when computers because the glitch would reset computers to Jan 1. 1900, rather than Jan. 1, 2000, because computers only used two digits to represent a year in their internal clocks<\/strong>.<\/p>\n

\"d\u00e9j\u00e0<\/a>Now it d\u00e9j\u00e0 vu all over again, BI<\/em> reports there’s a new, even bigger global software coding fiasco looming. \u00a0A huge amount of computer software could fail around the year 2038<\/strong> because of issues with the way the code that runs them measures time<\/strong>.<\/p>\n

Once again, just like with Y2K every single piece of software and computer code<\/strong> on the planet must now be checked and updated<\/strong> again. That is not a trivial task according to the author. In 2000, we bypassed the Y2K problem<\/a> by recoding the software explains Ms. Borison. All the software \u2014 a fantastically laborious retrospective global software patch.<\/p>\n

Disruption to the tech industry<\/h3>\n

\"Y2KAlthough Y2K was not a disaster, it was a massive disruption<\/strong> to the tech industry at the time. Virtually every company on the planet running any type of software had to find their specific Y2K issue and hire someone to fix it. Ultimately, Y2K caused ordinary people very few problems \u2014 but that’s only because there was a huge expenditure of time and resources within the tech business.<\/p>\n

The 2038 problem<\/a><\/strong> will affect software that uses what’s called a signed 32-bit integer for storing time<\/strong>. The problem arises because 32-bit software can only measure a maximum value of 2,147,483,647 seconds<\/strong>. This is the biggest number you can represent using a 32-bit system.<\/p>\n

\"time<\/a>When a bunch of engineers developed the first UNIX computer operating system<\/strong> 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.<\/strong><\/p>\n

Glitch says it’s 1970 again<\/h3>\n

On January 19, 2038<\/strong> \u2014 2,147,483,647 seconds after January 1, 1970 \u2014 these computer programs will exceed the maximum value<\/strong> of time expressible 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\u00a0to zero, thinking that it’s 1970 again.<\/strong><\/p>\n

UNIX time<\/a> coding has since been incorporated widely into any software or hardware system that needs to measure time.<\/p>\n

BI<\/em> spoke with Jonathan Smith<\/a>, a Computer and Information Science professor at the University of Pennsylvania<\/a> for confirmation. The professor confirmed the\u00a0Year 2038<\/a>\u00a0is a real problem<\/strong> that will affect a specific subset of software that counts on a clock progressing positively. He elaborated:<\/p>\n

\"\"<\/em>Most UNIX-based<\/a> 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 … 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<\/em><\/p>\n

The article concludes that we all need just to switch to higher bit values like 64 bits<\/strong>, which will give a higher maximum. In the last few years, more personal computers have made this shift, especially companies\u00a0that have already needed to project time past 2038, like banks that need to deal with 30-year mortgages.<\/p>\n

\"64<\/a>Apple<\/a>\u00a0(AAPL<\/a>) claims that the iPhone 5S is the first 64-bit<\/strong> smartphone. But the 2038 problem applies to both hardware and software<\/strong>, 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 is more of a logistical problem than a technical one.<\/p>\n

\n

HowStuffWorks<\/a><\/em> reports that some platforms have different dooms-days.<\/p>\n