Fun with data validation

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.