Leap Years, Global Warming, and System.DateTime

Tuesday, March 23, 2004

It is a little late to discuss leap years, since February 29th has already passed, but you never see what goes awry in any given leap year until after the magical date has passed.

CNN has an article about a leap year related glitch in the Pontiac Grand Prix. The display shows the wrong day of the week now, and the possible solutions range from resetting the software to completely replacing the display unit.

Have you ever wondered how many hours modern civilization has spent wrestling with the concept of a leap year? It’s the classic case of a business rule with a twist. Your unit tests look pretty simple when the analyst says “always place the order with the supplier who has the lowest price”. Then suddenly, almost as an afterthought, “oh, except on the last Friday of each month, then we need to place the order with the preferred supplier”. Suddenly, the test cases quadruple.

So in coming up with an estimate for hours lost to Leap Year, I thought of all the coders over the years in RPG, COBOL, Fortran, and assembly, and the myriad of languages where the leap year algorithm has been implemented time and time again by everyone from seasoned professional to college student.

Then consider the number of times a software leap year algorithm has been defective. We know older version of Lotus 1-2-3 and Excel both had the bug, but even new stuff like Grand Prix cars and personal video recorders appear to hiccup. Sometimes the leap year bug poses problems in obscure places (why is my Kerberos authentication failing this year?). Other times, just trying to deal with the quirky date in a thorough manner gives you unexpected side effects, like blogging software with only 29 days in January.

Working in .NET, we all know there is a static method on the System.DateTime class with the name IsLeapYear. Problem solved? Hardly – but the mention of DateTime keeps the post relevant to .NET.

Leap year isn’t just a software issue. Consider the company who pays salaried employees every Friday. Only this year, there are 53 Fridays in the year instead of the typical 52, an occurrence we won’t see again until 2032. As a well compensated CEO, you need to spend many hours with other executives to answer the following multiple choice question:

In order to reconcile the extra pay day in 2004, do we

a) Decrease the weekly pay of all salaried employees to compensate for the extra pay period, with a possible loss of moral.

b) Keep the weekly pay the same for all 53 weeks, in effect giving ~ 2% bonus.

c) Switch to bi-monthly paychecks.

d) Outsource all salaried employees below the VP level and sublease the office space.

Even PhD candidates sometimes forget about leap years, and this leads to increased global warming.

Finally, when considering an estimate, think of the 4.1 million people worldwide who have been born on Leap Day. Think of the hours they and their parents have agonized over when to celebrate the birthday during non leap years. Consider the poor fellow in Ann Arbor who was born on leap day, and carries a driver’s license that expired on February 29, 2003 – try entering that date into a rental car system.

So let’s make a rough estimate. 6 billion people in the world. On average, let’s say 15 minutes of each person’s life is devoted to resolving Leap Year issues. That’s roughly 170,000 hours the current population has lost. Not that we can really do anything about the situation, because changing the calendar usually requires an act from either the Pope or an emperor, so your local congressperson stands little chance. In software it will just be one of those business rules in the  “hard requirement” category.

Jason N. Gaylord Thursday, September 16, 2004
Interesting post. I'd have to say the answer is 'D'. ;)
Comments are closed.

My Pluralsight Courses

K.Scott Allen OdeToCode by K. Scott Allen
What JavaScript Developers Should Know About ECMAScript 2015
The Podcast!