Question

Microsoft has just announced that a software error in calculating dates (over leap year) caused a major outage in Windows Azure last week.

Was it really a simple error in judgement working around DateTime.Now.AddYears(1) on a leap year?

What coding practices could have prevented this?

EDIT
As dcstraw pointed out DateTime.Now.AddYears(1) on a leap year does in fact return the correct date in .NET. So it’s not a framework bug, but evidently a bug in Date calculations.

Answer 1

Shameless plug:

Use a better date and time API

The built-in .NET date and time libraries are horribly hard to use properly. They do let you do everything you need, but you can’t express yourself clearly through the type system. DateTime is a mess, DateTimeOffset may lull you into thinking you’re actually preserving the time zone information when you’re not, and TimeZoneInfo doesn’t force you to think about everything you ought to be considering.

None of these provide a nice way of saying “just a time of day” or “just a date”, nor do they make a clear distinction between “local time” and “time in a particular time zone”. And if you want to use a calendar other than the Gregorian one, you need to go through the Calendar class the whole time.

All of this is why I’m building Noda Time – an alternative date and time library built on a port of the Joda Time “engine” but with a new (and leaner) API on top.

Some points you may want to think about, which are easy to miss if you’re not aware of them:

• Mapping a local date/time to one in a particular time zone isn’t as simple as you might think. A specific local date/time might occur once, twice (ambiguity) or zero times (it’s skipped) due to daylight saving transitions
• Time zones vary historically – more than TimeZoneInfo is generally willing to reveal, frankly. (It doesn’t support a time zone whose idea of “standard time” changes over time, or which goes into permanent daylight saving time.)
• Even with the zoneinfo database, time zone IDs aren’t necessarily stable. (CLDR addresses this; something I’m hoping to support in Noda Time eventually.)
• Textual representations of dates and times are a nightmare, not just in terms of ordering, but date separators, time separators, and odd things like genitive month names
• The start of the day isn’t always midnight – in Brazil, for example, the spring daylight saving transition moves the wall clock from 11:59:59pm to 1am
• In some cases (well, one that I know about) a time zone can force a whole day to be skipped – December 30th 2011 didn’t occur in Samoa! I suspect most developers can probably ignore this one, but…
• If you’re going to use a calendar other than the Gregorian one, be careful and make sure you really know how you expect it to behave.

As far as specific development practices:

• Think about what you’re really trying to represent. I expect the core benefit of Noda Time to be forcing developers to choose between various different types to represent their data. Get that right, and everything else is simpler.
• Unit test everything you can think of. That will depend on exactly what your system does, of course, but particularly consider different time zones, what happens across daylight saving transitions, and of course leap years.
• I’d advise injecting a “clock-like interface” – a service for telling the current time – rather than explicitly calling DateTime.Now or DateTime.UtcNow; it makes it easier (feasible!) to unit test
• If you’re performing multiple operations with “now”, obtain that date/time once and remember it, rather than repeatedly requesting “now” – otherwise the value could change in unfortunate ways between the calls.
• “Do everything in UTC” isn’t always the answer either – if I want to know “when exactly does ‘two weeks from now’ occur in my local time zone?” then I need to store the local date/time as well as the time zone.