As we enter February, it's a good time to remember that 2016 is a leap year. For most people, this may just be an interesting oddity; an extra day to work or play. But for software developers, the leap year can cause significant pain.

If you are just now thinking about checking your code for leap year bugs, you better move quickly. In fact, you might already be experiencing the effects and may not even realize it! What kind of bugs might be lurking in your code?

• Off-by-one issues, especially around data filtering using date-range queries
• Unexpected or undesired behavior in user interfaces
• Potential for exceptions, crashes, or hanging as edge cases are encountered

“Meh,” you say. “My code is just fine. We have unit tests.”

“Oh really,” I say. “Do your tests properly mock the clock? Do they test edge cases including February 29 and December 31? Have you tested any low-level C++ code you might have as well as the rest of your system? Do you even know what a leap year bug looks like?”

Most often, blank stares.

Why does this matter for Azure?

Well really, it applies to just about any code a developer might write, and quite a lot of it may end up running in the Azure cloud! Azure had a leap year outage of its own in 2012, and we've been working hard to ensure a smooth experience this time around. We'd like all of our customers to benefit from our research and experiences since then.

Ok, so what do I need to know?

There's a lot to cover here, so let's start with the most important things first.

• February 29 is not the only day affected by the leap year. Another very important date is December 31, because it is the 366th day of the year and many applications mistakenly hard-code a year as 365 days.
  
  • With particular consideration for the cloud, also consider the vast majority of cloud applications use UTC (Coordinated Universal Time), or at least, they should. That means at midnight on February 29, it may actually be some other time in your local time zone. For example, in the US Pacific time zone, the leap day will hit UTC when it is 4:00 PM on February 28 (the previous day on the calendar). Check times in other time zones.
  • If you are preparing to monitor your system in real-time for leap day issues, you should be considering the three-day window from February 28 through March 1. Likewise, you should watch out for day 366 issues from December 30 through January 1.
  
  
• Leap year bugs can be found anywhere, in any language, but are most dangerous in C / C++ code, where they can cause application crashes or buffer overflows (which are a security risk).
• Past leap years have included some high-impact, high-profile bugs, such as:
  
  • 2012 Microsoft Azure outage: Miscalculation of a certificate expiration date caused service disruptions for up to 12 hours
  • 2012 TomTom GPS navigation bug: Caused many models to fail to identify their current location
  • 2010 Sony PlayStation Network outage: Caused by misidentification of 2010 as a leap year
  • 2008 bricking of all Microsoft Zune devices: Caused by a logic error on December 31
  • 2008 Microsoft Exchange management bug: Prevented administrators from doing much of anything on February 29
  • Lotus 1-2-3's miscalculation of year 1900, which still impacts Microsoft Excel today, over 30 years later!

These are just the big stories that made news headlines. I'm sure thousands more occurred with varying degrees of impact and noticeability. Another lesser-known leap year bug from 1996 actually caused process control systems at aluminum smelting plants in New Zealand and Tasmania to shut down abruptly at the stroke of midnight on December 31 (the 366th day).

This resulted in millions of dollars in damage to equipment as temperatures of molten metal went unregulated. Stories from yesteryear like this one remind me of the real-world dangers of software glitches. Considering the recent widespread adoption of IOT and its intersection with cloud computing, we should all be on high alert...

Read more: Is your code ready for the leap year? | Microsoft Azure Blog

Posted By: Brink
03 Feb 2016