Leap Year Woes in Japan
joerg writes, "The Heise-Newsticker says that Japan had several intercalary day-related computer problems like weather stations delivering wrong data.
" Finally! A Y2K bug! The hype was justified! (cough, cough)
Anyone have a birthday today?
Gotta love Drude this made the headline on DrudgeReport....check it out here at yahoo....the report makes more sense in straight english :)
I remember watching a number programs displaying the date 29 FEB 1990 to me a decade ago. That wasn't a leap year. Fortunately for the vendor, who responded quite quickly, the dates were stored internally in Julian format and converted for display, so no data was corrupted. The bug was introduced during some maintenance on some old software. I suspect that they were among the first to start Y2K fixes.
This particular problem arose from the fact that far few programmers completely understand the leap year rules, and the code that does the calculations is rarely touched, usually for some reason not directly related to leap year calculations, such as Y2K remediation. It is all wound up in the reasons why software maintenance gets expensive in nearly every case. The specs were either never written down to the level of individual functions, or they are out-of-date. Comments are incomplete or misleading. There's no automated regression tests to give assurance that nothing has been broken.
Why should we care about this? This particular instance was probably due either to Y2K work or a latent bug from some programmer who over-applied the century portion of the leap year rules. Once it gets fixed, this code won't need to be touched for ages. First of all, Y2K was just a single instance of a justification for going through bodies of code making huge numbers of small changes. Porting is another one. And any programmer with a bit of experience can name at least one or two others.
Earlier, I provided a link to the description of the Extreme Programming practice of automated unit tests. Doing that might not have caught these bugs before they got loose. Testing generally only catches the bugs you know to look for, and the tests can be wrong too. But I'm lobbying here to try to overcome the natural resistance many programmers feel toward testing. I know I'd certainly rather be writing code. The reason I've started automating it is because I have no such aversion to building tools to take that dull task away from me. Larry Wall pointed out that laziness is a virtue for programmers. Use it.
The net will not be what we demand, but what we make it. Build it well.
A friend of mine's son was born today! Although his wife went in to labor at 3am yesterday, we encouraged her to hold off for 24 hours to deliver just for the cool birthday.
I don't think she was amused.
SteveIt may be the case that there have been many more Y2K problems occur than have actually been reported. It may well be that organizations have tried to cover up to avoid looking like they were the only ones who didn't prepare for the worst.
It just so happens that the organisation which I work for had at least 20 Y2K related incidents occur in the first week of 2000 but we have all be told to keep quiet (hence I don't give the organisation name) I can say this: we are one of the largest organisations in the UK and we must have done damn well to keep information about these problems away from the trade press.....
Ripping an new rectum in the fabric of spacetime.
If you call that a translation...
Disclaimer: I'm not a native English speaker (it shows), and I'm not a native German speaker, but I do think my poor translation is easier to understand than the babelfish one.
Here.
It's intersting to note they did have problems with Y2K (according to the BBC), so this shouldn't have been *too* much of a surprise...