Z2k9 Bug Strikes The Zune

From the company that brought you Windows ME, and Windows Vista, Microsoft Corporation today introduced the world to the Z2K9 bug. Apparently all 30GB Zune’s reboot and freeze due to a bug in the date/time drivers. Classic. Microsoft’s solution is to simply wait until 2009 (a few more hours). Even more classic.

This does bring up one of every programmer’s biggest pet peeves: date/time code. I’ve mentioned my hatred of time before. It’s one of the most obnoxiously complicated things to work with due to all of the complexities from leap seconds to leap years. If you need to do something involving old dates, it gets even more complicated. Remember Julian Thursday, 4 October 1582 was followed by Gregorian Friday, 15 October 1582. Yes you read that right. Also don’t forget that only certain countries (mostly those under strict influence of the Pope) switched on that date. There was dual dating for some time. Then you have timezones, which ideally would be geographically correct and 15° of longitude apart, but instead zigzag and not even along territorial borders. Worst of all is daylight savings time. Not everyone participates in that, and sometimes just not every year, or at the same time. Even states are split, just check out the chaos in Indiana.

Griping aside, none of these likely caused the Zune bug. Since it’s a freeze, I’d guess it’s nothing more than an infinite loop or some other trivial programming error on a leap year.

Everyone remembers the infamous Y2K bug. Many uneducated folks still claim it was nothing to worry about and overblown, but it still cost between $300-600 billion dollars depending on whose estimates you believe (3.596 billion from the US military alone). Since a large portion of the cost was in the private sector, there’s no true tally.

The next big day to keep in mind is January 19 2038 3:14:07 GMT. That’s when the 32 bit computing will officially freak out since most Unix-like computers store time as a signed 32 bit integer counting the seconds since Jan 1, 1970 (Unix Epoch). After that we go back to 1901. There will likely be some 32 bit computing left in 2038 considering how long embedded systems can be ignored and silently slaving away in the background. For reference the B-52 Stratofortress entered operation in 1955 (they were built until 1962). They are expected to be taken out of service in 2040. This is the exception for US military aircraft, but don’t think this is the only old hardware out there. The Hubble Space Telescope has a 32 bit 486 processor and launched in 1990 and assuming the backup computer is functional it will be serviced soon to extend it’s life by another few years making it’s service life 20+ years. It’s unlikely Hubble will make it to 2038 but Hubble shows how long expensive systems can survive in active use. This date is only 30 years away. This will cost the world some serious cash.

On the upside according to Wikipedia 64 bit systems will be good until Sunday, December 4, 292,277,026,596. Odds are that won’t be a concern for most people alive today.

Reassuring? Yes. But your Zune is still fried for a few more hours.

Update [1/5/2009]: Here’s some pretty detailed confirmation that it was indeed an infinite loop error. I know my crashes 😉 .

Time Sucks

One of the hardest things to program is the Date and Time. This is especially true when your doing it on the web. Why is that? Using a unix timestamp is immensely helpful and resolves many of the complexities, but it does have some issues (besides the Y2K38 bug). Well lets take a look at some of the “typical” things you need to be aware of:

  • Your server is in one timezone, your users are in 23 others.
    Users don’t care what the time is at the site. They want things in their time.
  • Does your server even know your users timezone?
    You could do this with JavaScript, and send it to the server, but that’s a mess. Or send a timestamp to the client, and let JavaScript print it out. But that’s still messy.
  • Timezones aren’t obvious (think Indiana).
    Did you know some even use :30 such as UTC-3:30 for Newfoundland Standard Time.
  • Looking back in time (or forwards) is difficult (how many hours between X and Y accounting for leap years, and DST changes)?
    This is a mess, enough said. And just in case you have a formula, did you account for the conversion between Julian and Gregorian calendars? Don’t forget not everyone switched in 15 October 1582 / 4 October 1582. Going forward remember we’ll eventually have another leap day, since the Gregorian calendar isn’t perfect.
  • Your server observes DST. Does your user? When?
    Get the picture? Remember most states do, except for Hawaii (yea, that’s another Timezone) but Arizona doesn’t either, except for Navajo Nation. Again Indiana!
  • The Politics of Time…
    If you call UTC+2 Israel Standard Time, you upset visitors from Muslim nations like Egypt. Call it Central Africa Time, or Egypt Standard Time and your considered anti-semitic. Same goes for UTC+8, is it Chinese Standard Time or Hong Kong Time? Most avoid this by just listing UTC±N. Unfortunately this confuses people, especially Americans who only refer to timezones as “Eastern” (UTC-5), “Central” (UTC-6), “Mountain” (UTC-7) “Pacific” (UTC-8). Note these American names aren’t so common in all of North/South America.
  • Daylight Savings Time for 2007+
    Then you have a bunch of clowns who voted for the Energy Policy Act of 2005, creating the Y2K7 bug. The idea was an extra hour of daylight in the evening would reduce electrical use. What they didn’t realize is that it cuts daylight from the morning. My guess would be a follow up bill may fine the sun for failing to provide adequate light, and eventually include economic sanctions. 😛

I thought a while back this could suck. Think about all the time/money that goes into updating and testing systems for these few extra weeks of DST. What a drag.

Swatch Internet Time was an obvious bust, but perhaps we could all just use UTC?

Daylight Savings Extended?

I’m curious what the tech community thinks about extending Daylight Savings Time. Daylight Savings has long been a pain in any developers side as it varies depending on timezone (and sometimes country). It’s the reason why many webApps stick to GMT or UTC, rather than allow users to customize to their own timezone. No matter what it seems a few people don’t get the correct time unless you use GMT. Will this be another y2k?

Coding with Timezones

I’ve got a bit of a complex question here for all you professional web developers:

Environment
Website targeting international users in all 24 timezones. Website based in US.

Problem Summary
How do you handle timezones correctly? What is the best strategy?

Problem Expanded
The particular problem I see is Daylight savings. I’ve seen several sites ask it based on GMT (-5 for New York for example). Now what that misses is Daylight Savings. Not everyone in all timezones participates, and each has a different time when they implement it. Keeping it in GMT isn’t exactly desirable either, since users need to know the time (in their timezone).

Anyone take on the issue? I’ve searched high and low, and yet to see a good solution. Most just leave it as GMT, or hide times (put it in very low contrasting color compared to it’s background for example).