Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 3182 - new timetool is not Y2100 compliant
Summary: new timetool is not Y2100 compliant
Keywords:
Status: CLOSED DUPLICATE of bug 3144
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: timetool
Version: 4.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-05-31 19:49 UTC by jrs
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-06-01 14:26:17 UTC


Attachments (Terms of Use)

Description jrs 1999-05-31 19:49:30 UTC
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 1 Dale Lovelace 1999-06-01 14:26:59 UTC
*** This bug has been marked as a duplicate of 3144 ***


Note You need to log in before you can comment on or make changes to this bug.