2010 as a leap year? is that why they released the film Leap Year this year as well?

Probably about as many as there are incompetents who tell them what to do. If the programmer sitting opposite me had any hair he wouldn't have now, after discovering that the muppets who told him what to do neglected to say that the biggest branch is still on Notes 6 rather than Notes 8.5 he built the new business system for.

The algorithm "Years ending in zero are leap years" worked fine for every date from 1991 (which was before the original PlayStation was launched) up to last weekend. It may have been ancient crufty code from the mid nineties that no one expected to still be in use fifteen years later.

It's a pig-awful algorithm because, if you're looking only at the last digit, then you've already got problems with (say) 1998 and 2008.

(I can accept the simple 'divide by 4' algorithm because that one works for 1901 through to 2099, which is a reasonably long period that we might well have calendar reform before its end.)

Is there a standard library which can perform this algorithm for me?

I'm wondering if there's a standard library that doesn't.

if (year%4==0 || year%10==0) {
  monthdays[2] = 29;
/* I'm sure there was something about years divisible by 100, but the test guys can catch that. */

if (year%4==0 /* || year%10==0 BUGFIX 2010-02-29 2010-03-01 Not a leap year after all*/) {
  monthdays[2] = 29;
/* Test guys only tested till end of 1994. */

Perhaps something got confused about whether it is dealing with Gregorian years or years since 1970.

Nope, that would have gone horribly wrong in 2008, 2006, ...

I can understand the Y2K10 bug, where programmers were confused as to what comes after '9' and decided both '10' and '0A' did. But this one has me foxed, because it appears to be incontrovertibly a leap-day issue, and I can't think what algorithm they could have been using to get this year wrong.

Hmm, I had got the impression that the PS3 was newer than 2008 from the news items. Still, if some lower layer calculates leap years from 1970 and this screws up the upper layers, this will be the first year that could have triggered it since the PS3 was released in late 2006. (I guess the 2008 leap year was handled by the upper layers.) Perhaps the lower layer is the clock chip, and the different slim PS3 hardware fixed this bug. But this is all completely unfounded speculation.

Ah, mobbsy suggests that BCD may be the answer: if the clock rolled from 0x09 to 0x10 and this was interpreted as 16 not 10....

Now that is plausible.

Yep, if that turns out to be the answer, I can understand that. (Though I can't see why anything in a PS3 would want to use BCD, it's conceivable that it did one bit of arithmetic in the wrong mode.)

I can't even figure out how you'd make that error. An off-by-one is understandable, though novice-like - but an off-by-two?

I think fanf may just have indicated what happened - something thought that 0x10 follows 0x09. Meaning it may be an off-by-six error.

Oh, hmm. That could be, actually. That's impressively terrible programming right there.

BCD is a pretty odd thing to find in something as new as this, though it's conceivable that a clock chip has a BCD year count output, and the code reading it assumed that it was outputting in hex.

A quick check with the calendar indicates that from Jan 1 to Feb 28, all the week days in 2010 and 2016 are actually the same - and it's only that 2016 has an intercalary day that causes the mess-up.