Dates and Times - Software's Bane

I’ve always been amused by date and time problems in software, and in my mind I often juxtapose “real” time against “software” time.  Real time inexorably marches forward, while software time can go forwards, backwards, left, right, and sometimes belly up. Inside this theater of my brain, real world time is played by a dead panning Steve Martin, while software’s interpretation of time is a buffoonish John Candy. You can’t help but laugh at the contrast – it’s a classic comedic recipe.

Naturally, I chuckled when last week’s Zunicide turned out to be leap year related. I also giggled at the Pontiac gaff, chortled when I read about crashed DVRs, tittered over the stalled Norwegian trains, and cackled at Cisco’s Kerberos slipup. For non stop laughs I can read the Leap Zine -  a birthday club for anyone born on February 29th. The stories the leap babies can tell are endless. Problems with driver licenses, insurance policies, and rental car companies. The list goes on and on. Some leap babies alter their birth certificates just to avoid the entire mess.

Do leap years represent an edge case? That was one of the topics for debate today on Twitter. I don’t believe leap years fall under the strict definition of an edge case, but they are obviously tricky enough that we’ve consistently screwed them up - and it’s not always a laughing matter. In 1996, a leap year bug shut down 660 computers at a New Zealand aluminum smelter and cost the plant over $1 million in repairs. I’m sure they fixed the bug, but I think there is still a problem with their pronunciation of aluminum. It’s 4 syllables, everybody – ah-LOO-meh-num.

There are also numerous time bugs in software that aren’t leap year bugs. Remember the Win98 date rollover bug? Ever used software with an inadvertent time bomb? How many glitches exist because of the two digit year? Developers are cursed when it comes to date and time handling. And just when you have it figured out, some government, or Pope goes and changes the rules.

Leaps and Boundaries

Q: Why shouldn’t the following test pass?

[TestMethod]
public void A_Name_Would_Give_It_Away()
{
    DateTime almost2009 =
         new DateTime(2008, 12, 31, 23, 59, 59,
                      DateTimeKind.Utc);
    DateTime newDate = almost2009.AddSeconds(1);

    Assert.AreEqual(2009, newDate.Year);
}

A: Because 2008 included a leap second. Technically, the last second for 2008 on the UTC clock was 23:59:60 (not that any runtime I’ve ever used correctly accounts for leap seconds).

If leap years are a minefield for developers – at least they are a predictable minefield. We know when leap years will occur in the future. All we need is the diligence and thought to write some proper algorithms. Leap seconds are a different matter.

Q: How many UTC seconds will elapse between now and January 1st, 2012?

A: Nobody knows

Leap seconds are a periodic adjustment made to UTC time. The IERS announces the need for a leap second in a bulletin they publish every 6 months. Maybe we will have a leap second this year, maybe not. We have millions of seconds elapse in a year, though, does anyone care if we miss just one?

Ask the makers of a Motorola GPS receiver that is rumored to be utilized in some fast moving, explosive munitions.

If time wasn’t so important to civilization, I think we’d try to circumvent all these problems by just not mixing clocks with computers.