Try again tomorrow - leap year bugs

Around about 20 years ago, I left my first job at Frontier Software after 2 years. All the code was in COBOL, and it was some of the best, cleanest code I’ve ever seen. For common code, we would just include libraries to reuse standard functions. I can remember reading the date routines and the obscure logic of the leap year calculations. These days, most languages provide standard libraries of functions, so all the hard work is done. Does this mean that programs all handle leap years now? Apparently not, in fact the situation is so poor that “The honor society of leap year day babies” has provided a code snippet for programmers to re-use. They acknowledge it isn’t the best, and it is just in perl, but they are not programmers just frustrated users (looking for programmers to provide other examples). They have actually updated the code and added a ruby version as well, but being unfamiliar with change control, the new version is hidden as a link off the old page. So what are some of the things that frustrated them? Systems that refuse to allow Feb 29 in a leap year as a birthday. A ToysRus birthday card system that won’t accept leap day birthdays, YouTube (since fixed), Nickelodeon and Pampers, and assorted government systems . The workaround is typically to force a choice of a day before or a day after, which is effectively corrupting the information. No wonder they are annoyed.

There are also bugs caused by the day itself when the code cannot handle 29 days in February. There were issues at Microsoft with a preview of SQL Server 2008 (just 2 days after the launch), Microsoft Exchange 2007 and Windows Small Business Server, and an ongoing bug with a function with European date formats. United Airlines lost their self-checkin . Motor vehicle registry systems in the US were “affected”, as was a solitary Starbucks . There were also issues with an Apache function , the FTP function in Ant, Hewlett Packard’s HP Media Smart Server , and an unconfirmed coldfusion issue. The webcam on the Mount St Helens volcano had an issue as the “cam’s software and hardware were actually battling over what date it was, but the ignorant hardware kept winning the battle” so Feb 29 simply became March 1. Given the remoteness of the camera, any corrections will have to wait until winter is over.

While all these issues should have been found by code reuse, review or testing, there is evidence of developer brainstorming around the leap year topic. Here is some JavaScript code with discussion. (Just don’t listen to Owen!) The leap year bug may be a small issue overall, but it is a very important one at the same time. While I have been lucky to work with good developers most of my working life, the fact that something as well known and defined as this still causes problems in our industry is scary. Let’s hope that in another 4 years Owen and his friends have changed careers, and all our systems let our leap day friends enter their birth dates, and Feb 29 is just another day…..