As a few people have found out, the Y2K bug came back to bite some products. It’s not the nightmare scenario that the media predicted for January 1, 2000, but it is an issue that raises questions. Such as “Why did this happen?” “Why wasn’t it fixed the first time?” “Will it happen again?”
A little history and a lesson first…
In the 1990’s (actually earlier but the issue was raised during the 90’s), software developers realized that they had a problem. Their programs and operating systems used a two-digit format for years (yy). When they got to 2000, they were going to have issues with the dates, because the dates would show up as negative numbers (or just the wrong dates). So, they scrambled to fix the problem—and succeeded since Y2K didn’t turn out like the Media thought. They had to fix millions or billions of lines of code, so they took shortcuts in some cases. Which leads us to Y2K Round 2…
One of the shortcuts that they used was basically this:
IF year < 10 then
dateValue = 110 – year
This would guarantee them accurate dates up through 2010. And in theory, give them 10 years to find all of the code and fix it. But, somewhere along the lines, people said “Well it wasn’t that big of a deal, so we’re not going to waste time or money on fixing this.” Or other reasons/excuses were given for not fixing the code.
So, here we are at 2010 and guess what happens. Programs that were fixed with this quick-fix-engineering are breaking. ATM’s, some security and antispam suites, and other programs are rejecting updates and not working properly. So, companies who didn’t post updates are scrambling to fix this in any way they can.
One company is sending their updates out as of December 31, 2009 until they can fix the problem.
One company did the novel thing and changed the IF statement to 20…. Yeah, that’s a fix. It’s just going to create the problem in 10 years (unless they ACTUALLY fix it this time).
“Why isn’t this affecting everyone and everything?” you may be asking. Well, that’s because some companies took it a step further. Instead of saying 2010 (or 110) they extended everything out to 2038. Microsoft had already factored this in when they created MS-DOS 3.3x and above. If you have one of those old DOS Disks (and a way to run it), put a year in like 30 and see what you get. If the year is below 38, it will show up right.
So, the last question is, “Will this happen again?” It very well could in 10 years or 28 years. A lot of this depends on whether IT departments (and the creators of compilers) look at this as a warning shot. If they do, and they budget in to fix their code, then everything should turn out right. However, if they choose to ignore the few cases because “It wasn’t the end-of-the-world that we thought Y2K would be”, then I really don’t think you’ll like January 1, 2039 very much.
For non-developers, check your information (bank statements and such) and make sure everything’s still working right. For developers, start fixing that code. Change the dates to 4 digit years, instead of the two-digits that they currently show. If the compiler doesn’t support that, maybe it’s time to migrate to one that is more current.
For IT managers, if you have “in-house” code, then I suggest you start budgeting in for fixing this issue. You’ve got a few years to go, but you’ve also got a lot of lines to go through. It’s not going to happen overnight. I’d make the most of every minute you have.
Have a great day:)