Julius Caesar is credited with inventing leap year in 45 B.C., with improvements added by Pope Gregory XIII in A.D. 1582. By my count, that means that humans have had more than 2000 years to get used to the idea, and more than 30 years to figure out how to account for leap years in computer code. That raises a reasonable question: Why on earth did Exchange Server 2007 administrators have a leap year problem on February 29 of this year?
If you don't know what I'm talking about, consider yourself lucky. The problem manifested itself if you started or restarted the Exchange System Attendant service between midnight Coordinated Universal Time (UTC) on February 29 and midnight UTC on March1. During that time period, the System Attendant would refuse to answer requests for address list management services. If you tried to perform common tasks that require these services, the tasks would fail with an error indicating that "The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error." This isn't a particularly helpful error message; typically when you see it, it's an indication that the System Attendant isn't running and needs to be started.
I don't have solid information on how widespread this problem was. However, it was widely reported on the Internet, and Microsoft felt that it was pervasive enough to mention it on the Microsoft Exchange Team Blog. It's true that the impact of the problem was fairly minor: Restarting the System Attendant after the time window solved it neatly. However, it's worrisome for another reason: Mistakes like this go a long way toward eroding the customer confidence that Microsoft has worked so hard to build. (It certainly doesn't help that the technology preview of Microsoft SQL Server 2008 fell victim to the same problem!)
What do I mean? Consider security. For years, Microsoft had a reputation for poor security in its OS and server products. To counteract this, Bill Gates himself decreed that Microsoft would focus on security as a core priority. This focus has been expensive, but it has produced clear results: Microsoft's products are far more secure than they used to be, and Microsoft has both clearly communicated its strategy for developing more secure applications (the Security Development Lifecycle in particular) and executed on that strategy. As a result, Microsoft pretty much stands alone in the enterprise software field—simply because it has a strategy for how to make its products more secure!
Do we need a BillG memo about the importance of making Microsoft products properly handle the Gregorian calendar? Probably not; after all, this is a minor bug with limited impact apart from the embarrassment it caused in Redmond. However, I'm sure you remember the daylight saving time (DST) fiasco from spring 2007, and with the return to DST right around the corner, I'm certainly not looking forward to seeing what happens when that particular clock rolls over.