

The cause of the Zune leap year bug has been isolated to a Freescale date routine - divia
http://www.zuneboards.com/forums/zune-news/38143-cause-zune-30-leapyear-problem-isolated.html

======
aston
The thing that _kills_ me about this bug is that it's such an easy bug to find
in a code-review. Some person totally unfamiliar with the code asks "What
happens when that inner _if_ condition is false?" and MSFT is saved from yet
another embarassing gadget glitch.

~~~
demallien
What kills me is the fact that they have a while loop on the main thread of
the Zune, which wasn't tested for all possible values of input. I don't know
about anyone else here, but as an embedded software developer, that sort of
thing automatically sets off alarm bells for me. Such a situation would
definately be code-reviewed, _and_ heavily unit tested in a sane development
environment.

~~~
thras
If stories are true, Microsoft has some the most code-reviewed software in the
world. The levels of bureaucracy they have got to go through are tremendous.

First-generation Zune software was so bad that it made iTunes look good. On
the other hand, there was a seismic rift between first-gen Zune software and
second-gen. The new Zune client software has got one of the nicest, prettiest
UIs on my system.

I think that in order to generate the second-gen Zune software, a lot of the
bureaucracy must have been chucked. Apparently too much. It's really too bad.
I suppose that we have will have to make hard choices between stability,
features, and beauty forever.

------
mixmax
Bet there's a developer somewhere having a really shitty New Years eve right
now...

------
DenisM
Bugs happen. The root cause of this disaster is an incomplete test plan.

~~~
gruseom
There is no such thing as a complete test plan.

~~~
lionheart
But isn't this exactly the kind of thing that _should_ be in a test plan? Run
through all the possibly dates?

I mean, didn't we learn our lesson from Y2K?

~~~
jerf
Sure thing. We'll run it through all possible dates.

Well, you know, some actions may only have problems on certain dates, so make
that all possible actions on all possible dates.

Well, you know, maybe the meridian counts. So, make that all possible actions
on all possible dates in both the morning and the afternoon.

Well, we better test that with all the pathological media files we've built
up. So, make that all possible actions on all possible dates in the morning
and the afternoon with every one of our three hundred test music files.

Well... what if...

In hindsight it's always easy to identify the test that would have revealed
the problem. Given the ability of bugs to only manifest when five particularly
tricky conditions occur (and let's not even TALK about race conditions!), it
simply isn't possible to test them all exhaustively. Unit testing helps, sort
of, because it can run through a matrix faster than a human can, but it's also
dumber, and even unit testing can't exhaustively search a twelve-dimensional
space in any reasonable period of time if it's anything more than binary
values in those twelve dimensions.

That said, for date processing code, this is definitely something I would have
unit tested; that style of date processing is OK if you get it perfect, but
definitely inherently problematic. One case where I did write a fairly
exhaustive unit test was for billing code with a variable bill-on date;
getting every single case exactly correct took me a long time. I was up to
about three thousand permutations when I was done, and yeah, I'd see bugs that
only struck if you signed up on the 31st of a month followed by a month of 30
days, for instance. Easy to miss if you're writing on a 15th. (And that code
was probably thrown away... :( )

------
zitterbewegung
This sounds like a daily wtf posting in the making.

------
zhyder
The correct way to do this is to define a quadyear=365*4+1, and then just use
mods & divides (quadyear -> year-within-quad -> day) with no loop, right?

~~~
marcus
Not exactly its a bit more difficult, leap years occur once every four years
unless the year is divisible by 100 and not by 400

so 1900 wasn't a leap year 2000 was one 2100 won't be.

Although in most places I saw the code just ignored it as something that's
valid between 1901-2099 is considered good enough in most places.

Edit: sorry shouldn't post this early in the morning, its 400 not 1000

~~~
dwarry
No, century years are leap years if they are divisible by 400, so 2400 will be
the next such, not 3000!

~~~
marcus
Sorry, you're right. Changed the original comment.

------
tocomment
Why do they have access to the source code? Since when is Zune open source?

------
redorb
on zune.net it says this bug will work itself out noon tomorrow... still a bad
taste.

