Slashdot Mirror
Y2.01K
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."
Wait until Dec. 31, 9999. Watch as people panic about there being 5 digits in the year and how programs were only written to accommodate 4 digit years for the past 8000 years!
They are going to have thaw out a lot of old cobol programmers.
http://michaelsmith.id.au
Programmer: "I want to take some time to refactor some of the older code."
MBA: "What's the ROI on that?"
Programmer: "DIAF."
At least the situation is too embarrassing to file a bug report
// MD_Update(&m,buf,j);
A little bit of both!
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.
True.
We should start freezing them now, just to be sure.
"I've got more toys than Teruhisa Kitahara."