Y2.01K 269
After our recent discussion of decimal/hexadecimal confusion at the turn of 2010, alphadogg writes in with a Network World survey of wider problems caused by the date change. "A decade after the Y2K crisis, date changes still pose technology problems, making some security software upgrades difficult and locking millions of bank ATM users out of their accounts. Chips used in bank cards to identify account numbers could not read the year 2010 properly, making it impossible for ATMs and point of sale machines in Germany to read debit cards of 30 million people since New Year's Day, according to published reports. The workaround is to reprogram the machines so the chips don't have to deal with the number. In Australia, point-of-sales machines skipped ahead to 2016 rather than 2010 at midnight Dec. 31, rendering them unusable by retailers, some of whom reported thousands of dollars in lost sales. Meanwhile Symantec's network-access control software that is supposed to check whether spam and virus definitions have been updated recently enough fails because of this 2010 problem."
does the wii has a minor 2010 issue? (Score:3, Interesting)
Playing wii new years eve. The thing hard crashed exactly as the year changed (it was in the menu not a game). After a reboot it was fine.
Re:idiocy? Incompetence? (Score:3, Interesting)
> At the Bank of Germany, we're not happy until you're not happy.
Indeed. They even said if the cache machine in your branch did not work and you had to get money from a competitor, you will not get the fee reimbursed at most banks. So far only one bank has promised to pay them back.
Re:idiocy? Incompetence? (Score:5, Interesting)
We have actually had TWO different Y2K10 problems at our job. One was related to someone setting certain rules to expire in 2010, because, you know, it was so far off in the future they wouldn't be working here anymore.
The other bug qualifies as complete incompetence on the developer. We contracted another company to write some software to print barcode labels. They encoded pipe delimited values including a date. In order to save digits and thus reduce the size of the barcode they decided to take the year and append the Julian day. For example Jan, 6th of this year would be stored as 2010006. The problem was that they didn't feel that it was necessary to use four digits for the year. Which is understandable, but apparently TWO digits for the year was too much as well. So the end product was a one digit year ex. "0006". The code that reads the label was:
year = 2000 + barcode.left(1);
What's really scary, is that this code had to have been written post Y2K.
The worst part of the whole thing is that we have to go back to the contractor to fix the problem which is going to cost us $$$ beyond the lost revenue of downtime.
Now both of these problems have nothing to do with 2010 specifically, but it just shows how short sighted developers can be.
It's Y2K01 (Score:3, Interesting)
I think the proper way to denote year 2010 is Y2K01, just like 14K4 was used for 14400.
Of course writing Y2K01 or Y2.01K is more difficult than Y2010, so why bother using that arcane notation.
I can certainly vouch for this. (Score:4, Interesting)
Got hit by this one myself (Score:3, Interesting)
SunPCi cards are essentially x86 PC blades designed to be plugged into a PCI slot on a Sun SPARC machine. I use a SunPCi III in the Sun Blade 1500 (SPARC desktop) I have on my desk to run software I have to run that requires Windows. This Monday, I fired it up and got told by the driver software that my system date was in the future because "I can't believe it's really" 2010 (the exact words of the error message!). Looking at the Sun forum message traffic, apparently *everybody* with a SunPCi III card is getting this. Sun's supposed to be working on a patch now. Right now the only workaround is to set your system clock back to 2009 when you fire up the SunPCi card (you can set it back to correct after it starts).