It’s Leap Day – Does Your Software Know That?

Well today is February 29th 2008. A February 29th only comes around once every four years. Or does it? Actually some years that one might think are leap years are actually not. So in honor of today being leap year (and me not being especially creative) I decided to repost something I originally wrote in July of 2006. (I have no idea why I was thinking about leap year in July 2006 by the way.) Perhaps you can use it with your students today since it is a "found day."


I’ve been spending some time over the weekend thinking about interesting projects. I think that the best projects teach concepts in context. By that I mean they don’t just teach a concept but make it real and show how it is valuable. If you can teach complimentary concepts so much the better. Projects that involve If statements or other discussion structures in the context of validating date fit into this category.

One of the things that programmers have to do fairly often is validate dates. Students are tempted to take the easy way out and do a rough calculation: Month between 1 and 12, day between 1 and 31 and not bother checking the year at all. In the real world that will never do. In the real world one has to make sure there is the right number of days for the specific month. Often you really do care about the year as well. But for the moment let’s look at the days in the month problem. The big complication is of course February because it doesn’t always have the same number of days. This means the third commutation is to determine if a year is a leap year or not. Most students assume that any year that is evenly divisible by four is a leap year but that is not quite the case. In fact, pay attention now, years that are evenly divisible by 100 are not leap years unless they are also evenly divisible by 400. So 1900 and 2100 are not leap years. The year 2000 was a leap year though.

Obviously, doing a full verification of dates can be a bit more involved than many students assume. This opens the door to some interesting conversations about how good does validation have to be under different circumstances and can require programmers to write some fairly complex nesting of decision structures. As a teacher (or a tester) doing validation of date checking it also means one has to give some serious thought to test data. Just testing February requires at least four different years: a standard “not leap year”, a “regular” leap year, a year divisible by 100 and a year divisible by 400. This also opens the way for a discussion about how much serious thought has to go into a test plan. It all makes for a project that is about a lot more than just nested If statements.

BTW if you are looking for some reading on why leap year is the way it is you can visit this page on wikipedia or read this classic actual response to a bug report.

Comments (0)

Skip to main content