Disclaimer: I don't work for the Zune team and I don't know anyone on the team. I think that Z2K9 was a bummer, but I don't have any inside knowledge. Everything here came from the public interweb.

Dates will get you every time. Further more, it's all about Edge Cases. This is one of the things you'll think about when doing Test Driven Development and it's one of the things that everyone learns in Computer Science 101. You really have to hit those edge cases, be they dates, or number overflows, or buffer overflows.

The news reports:

"A bug in the internal clock driver related to the way the device handles a leap year affected Zune users," said the company in a statement. "That being the case, the issue should be resolved over the next 24 hours as the time change moves to January 1, 2009."

Disclaimer*2: I have no idea if the following is 100% true, only that it seems quite plausible. I present it for educational purposes, nothing else. It's very interesting. Again, I'm just a caveman .

A Zune Fan poked around in the source code from the vendor (Freescale Semiconductor) that made the real time clock in the Zune (The vendor's source for rtc.c is here) and with the benefit of hindsight, noted that there's the opportunity to get stuck in an infinite loop.

The Zune 30 shows the date and time, as do many devices, as the number of days and seconds since January 1st, 1980 at midnight.

year = ORIGINYEAR; /* = 1980 */



while (days > 365)

{

if (IsLeapYear(year))

{

if (days > 366)

{

days -= 366;

year += 1;

}

}

else

{

days -= 365;

year += 1;

}

}

The days variable is read out of the memory location managed by the Real Time Clock (RTC). When the value of days == 366, you break out of the inner loop, but you can never get out of the outer loop.

A number of folks have blogged about the bug, their analysis and how they'd fix it. Programming Phases has a good post and folks have twittered suggestions). The basic problem is that since there are 366 days remaining when the calculations are reached for the year 2008, there will never be another subtraction to bring the total below 365, so the loop continues. The value of days is stuck at 366. It IS a leap year, but days is not > 366, so the loop continues.

In working with banking software for years, I can tell you that dates'll get you. When dealing with dates and date math you can't underestimate the value of really good code coverage. Also, even if you have 100% coverage, as I learned in my interview with Quetzal Bradley, 100% coverage just tells you a line of code DID run, it doesn't tell you that it ran correctly.

I noticed also when I visited my Live home page on Dec-31 that it said today was Jan-1, likely a Time Zone glitch. However, when I clicked the date, I was taken to a page with historical facts about Dec-31. ;)

Dates, especially when TimeZones are added in, are notoriously hard.

To this day there are a half-dozen bugs in DasBlog where we have a devil of a time with Time Zones. Omar spent weeks fighting with them before he just gave up. We have to reconcile the local time of the visitor, the time on the server, and GMT time (the time we store everything in). It usually works, but when the Server isn't on GMT we get into all sorts of trouble. We also have problems with clients that call the XML-RPC APIs, some of which use UTC (GMT) time and some use local time. Other than keeping an internal table to wrong-headed clients, there are no good solutions.

In 2007 CNN talked to a Major General about a bug in some F-22's that caused them to malfunction when going across the international dateline. The Unofficial Apple Weblog had an interesting post on Apple Date/Time bugs through the years. If you're interested in working with and maintaining legacy code, I recommend Michael Feathers' Working Effectively with Legacy Code .

As a random slightly-related aside, I was over at Hollywood Video buying a used copy of Mirror's Edge yesterday and some folks were talking about the Zune problem. The manager said, wow, I'm running the music in here on a Zune right now, and produced his brown 30G Zune from behind the counter. He either hadn't turned it on today fresh or the clock was wrong so he was able to weather the whole day without an incident. He seemed pretty pleased about his "survival."

I wonder how many other less widespread devices are running this real time clock and if any of them had trouble as well.

Do you have any personal Date/Time stories, Dear Reader? Please share in the comments!