Sigh. I thought that one of the main differences between proprietary software and open source software was getting the job done vs. getting the job done *right*. I downloaded the new timetool-2.5-3 rpm, and took a look at how it was patched to fix the year-2000-is-a-leap-year problem. I was dismayed at the sloppiness. While I am not familiar with the scripting language it is written in [wish], I can see that the patch, as well as the original version, display a basic misunderstanding of the Gregorian calendar. In particular, both the old and new versions of the program incorrectly determine the leap status of years such as 1900 and 2100. They are *not* leap years. The correct rule is: Years not divisible by 4 are not leap years. Years divisible by 4 but not 100 are leap years. Years divisible by 100 but not 400 are not leap years. Years divisible by 400 are leap years. There are many sources for this information. For example, on a Red Hat distribution with gcal installed, see /usr/doc/gcal*/doc. Sloppy patches like the one you provided are the kinds of things that created the Y2K mess in the first place. ### Here's the relevant code in /usr/bin/timetool from timetool-2.5-3: proc days_in_month {} { global cl_month cl_year month_length if {$cl_month == 2} { if {[expr $cl_year / 4.0] != [expr $cl_year / 4]} { return 28 } if {[expr $cl_year / 400.0] == [expr $cl_year / 400]} { if {$cl_year == 2000} { return 29 } else { return 28 } } return 29 } else { return $month_length($cl_month) } } ### Here's a better (but untested) solution: proc days_in_month {} { global cl_month cl_year month_length if {$cl_month == 2} { if {[expr $cl_year / 4.0] != [expr $cl_year / 4]} { return 28 } if {[expr $cl_year / 100.0] != [expr $cl_year / 100]} { return 29 } if {[expr $cl_year / 400.0] != [expr $cl_year / 400]} { return 28 } return 29 } else { return $month_length($cl_month) } }
*** This bug has been marked as a duplicate of 3144 ***