Bug 3144

Summary: you still don't have leap years correct
Product: [Retired] Red Hat Linux Reporter: andylev
Component: timetoolAssignee: Preston Brown <pbrown>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 5.2CC: jrs
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-06-11 14:11:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description andylev 1999-05-29 18:54:56 UTC
You just issued a "fix" to timetool for RH 4.2 and 5.2 (I
have not seen the RH 6.0 version) to correctly note that
2000 is a leap year. But the program continues to be wrong
for "100" years. It will work for now (the next 100 years)
because you hard-coded an exception for 2000. Why not do it
right and be done with it? The simple rule is leap year if
divisible by 4 but not divisible by 100 unless also
divisible by 400. That's all. Not hard.

Comment 1 Dale Lovelace 1999-06-01 14:26:59 UTC
*** Bug 3182 has been marked as a duplicate of this bug. ***

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)
    }
}

Comment 2 Jay Turner 1999-06-07 20:53:59 UTC
Confirmed in timetool-2.5-5 also.  This fix should actually work quite
well.

------- Additional Comments From   06/07/99 17:17 -------
timetool is dead.  If it is in use 100 years from now, I'll eat my hat.  In any case, there will be a completely new time configuration utility available in the next version of Red Hat that will have things "done right".  If you are concerned about doing things "right" with timetool itself, you are right -- it is open source -- and you can change it.  Those who have complained that the fix is not 100% correct are also right. However, it seems senseless to issue another update at this point when the main problem is solved and a better solution is in the pipeline.

------- Email Received From  Andy <andylev> 06/11/99 03:26 -------

Comment 3 Preston Brown 1999-06-11 14:11:59 UTC
OK I don't want people to go home unhappy.  I'm going to slip-stream a
fixed version of timetool onto the updates ftp site, and update the
errata, but I don't think it warrants sending another announcement and
forcing tons of people who don't really need or care about the
"correct" fix to get it.

timetool-2.6 will be the version.