My psychic prediction about the Sony PS3 leap year bug

[joel]

So this recent bug with the older ("Phat") PS3 units not being able to connect to PSN, sometimes crashing, sometimes resetting dates to Jan 1, 2000 or Dec 31, 1999, is all over the news. My psychic predictions:

1. It will prove to have been a leap-year related bug. Why? Things started "just working" again with a *no update* "fix" that happened to start working... pretty much exactly as the day rolled over in the UTC timezone.
2. My bet is on buggy handling of a 30-year offset from the standard "Unix epoch" calendar (0 = the start of Jan 1, 1970 in UTC). Why? Because while 2010 is not a leap year, a 30 year offset would be 1980, which *was* one.
3. My bet on how it got there?
   1. Developer Alice uses one of the umpteen standard implementations of the Unix epoch calculation to represent the system time internally, because it is simple, readily available, consistent, and has no licensing issues.
   2. Designer Bob sees the default time when nothing else is available is 1970, and says "Hey, 1970 is silly, it should be 2000".
   3. Developer Clarissa says "Okay, no problem, we'll just add 30 to the year value" (mistake 1).
   4. QA gal Denise does some basic testing of the calendar, for example "the first leap year that the unit will be in production" (2008), and files a bug when he observes that 2008 is not being handled as a leap year.
   5. Developer Eustance, who has the most unfortunate name in this entire narrative, gets stuck with the bug and goes hunting. He realizes that the problem is because with a 30 year offset, leap years aren't lining up correctly, so he implements a quick hack to calculate the leap year "properly" (any bets on whether this hack handles the 100-year/400-year rules correctly? I thought not...) and hands it back. All is well... or so it seems.
   6. QA gal Denise, under time pressure for the release, checks that 2008 works now, and it does. Unfortunately, since she *doesn't* know the internal workings of the code, there is no obvious reason to test for the alternative corner case: times that happen during a "leap day" which have no equivalent in their "partner" year at the 30-year offset, leading to an illegal calculation and much *boom*.
   7. PS3s ship with horked code
   8. PROFIT!!!
4. And why this is happening only on the older "Phat" PS3s? Because at some point someone looked at the code mentioned above, saw the bug, and fixed it (I can only pray to $deity that they fixed it by MAKING THE BLOODY DEFAULT DATE AN OFFSET FROM 0 AND USING THE CALENDAR LIKE IT WAS INTENDED DAMMIT). However, since different generations of PS3 actually run on different hardware internally, they almost certainly have multiple builds, and when (if) this was merged back, it was *not* merged to whatever build the Phat PS3s run on. Oopsie.

The "best" part of this? Sony's blog said that they "hoped to have a fix within the next 24 hours". If by "fix" you mean "do nothing because the units cannot log onto PSN to download an update, but it will fix itself 24 hours after it started", sure. And hey, if we're lucky, they *might* even bother to merge the fix back to the correct build and release an update someday.

On the other hand, if this is the bug the next time it will bite is in 2014, and who's going to still be running a PS3 in another four years, right? And it's only one day every four years, for the oldest console generation, they'll just wear out by then, surely...

Sadly, unless someone intimately familiar with the software involved comes out and discusses it in ways that would probably cost them their job (at the very least put it at serious risk), we'll probably never know for certain.