To those that claim "dealing with dates is not easy", a really simple unit test would have caught that bug - like feeding the function integers from 1 to 1000 and testing that it did not crash for any of them. Bonus points for testing that it returned something sensible each time.
Sadly, this code probably wasn't unit tested at all.
The lookup table solution in the comments seems sane enough, Always nicer to do lookups than loops.
You could improve on it by pretty much runlength encoding the table. Instead of storing 0,0,0,0 just store the number of 0s, although then you might need to iterate instead of simple lookup which would negate the point of using a lookup.
Also seems like most RTC chips I've worked with store the year,date,month as BCD or similar, and deal with the rollovers as they occur, on the chip. Only Storing days since 1980 seems like a lot more work in software.
I do think it's quite right to put the blame squarely at MS for this though, a simple code review, or a quick test plan would have picked it up easily.
You don't just blindly trust a supplier without testing anything do you.
Users don't care who wrote the code, it was an MS product, and MS should have ensured it worked, by testing it. They did not. Hell, just give it to an intern and get him to set the clock on it to key problem corner case dates.
If a supplier gives VW some faulty tyres to put on a car, and the car blows up, the buck still stops at VW, it's their responsibility to ensure their product works, including anything it relies on.
It's easy to say "Hell, just give it to an intern and get him to set the clock on it to key problem corner case dates." in hindsight when you know there was a bug with dates. That's not really useful.
I'd be willing to bet Microsoft did all sorts of testing. The fact that there haven't been any other substantial bugs would indicate that.
"And I think the main lesson from this incident is not the usual refrain that Microsoft is lame. Rather it’s the even more commonplace observation that software is hard."
Pointing out how you could have caught a bug after you know what the bug is is not hard.
Come on now. Date bugs are very common. In the area of date bugs, leap year, rollover case bugs etc are very common.
It's extremely simple to just check the startup procedure, and make sure that nothing can go terribly wrong. Look for possible infinite loops, stack overflows, erroneous jumps etc standard testing stuff.
I discovered a date rollover bug in windows 98, which got some press at the time (Day after it released, I was working at a y2k company). This one wasn't quite as bad, just turned out that if you startup your windows 98 PC at a little before midnight (On any day), it messes up the date and thinks its the wrong day.
I'm sure there are other companies that don't test things properly, but excusing it isn't helpful.
Heck why didn't microsoft just write the code themselves instead of relying on someone else for that? It's pretty simple code.
Keep excusing them if you like, but it's just sloppy. I'd be amazed if something like that happened to the iPod, because Apple are anal about having complete control of everything, and it shows.
I think your fanboyism has wiped your long term memory to DoD specifications. They've had tons of bugs in their iPod/iPhone line. Remember the launch of the 3G? Mainstream magazines covered that fiasco.
Trotting out "fanboyism" is just lazy. It's just like if anyone disagrees with anything Obama says ever, they'll be labeled by some a racist.
Yes, I remember the iPhone 3g launch. I've had no issues with the iPhone apart from that 2 hour period or so waiting for them to fix their servers so I could activate it...
It all comes down to the fact that dealing with the Gregorian calendar (and time in general) is not easy. And that's because our system is based on the position of the planet in relation to the sun. Let's get on with implementing Metric time already.
Sadly, this code probably wasn't unit tested at all.