DN477620177

Subject: Bug Tcl 8.1 incorrect leap year handling in generic/tclDate.c - DN [1]

scripticsBugForm@auto.genned.post - 14 May 1999 - comp.lang.tcl

 Tcl 8.1 Bug:  Generated by Scriptics' bug entry form at
     http://www.scriptics.com/support/bugForm.html
 Responses to this post are encouraged.
 ------

 Submitted by:  Isaac Hollander
 OperatingSystem:  Sun Solaris
 Synopsis:  incorrect leap year handling in generic/tclDate.c

 ReproducibleScript:
     This is already reported as bugID 1985, but I can't figure out how to
     update an existing bug.  Please close out bugID 1985 and use this bug
     report.

     The leap year handling in the Convert() routine in generic/tclDate.c is
     incorrect.  Leap years are divisible by 4, unless it's divisible by 100,
     in which case it's a leap year only if it's divisible by 400.  Hence
     2000 is a leap year, but 2100 is not.

     The code is incorrect in all versions of tcl I've looked at from 8.0p2
     through the latest code in CVS.

 Patch:
 $ diff -c tclDate.c tclDate.c.orig
 *** tclDate.c   Thu May  6 17:32:51 1999
 --- tclDate.c.orig      Mon Feb 10 13:03:15 1997
 ***************
 *** 430,439 ****
           Julian += DaysInMonth[i];
       if (Year >= EPOCH) {
           for (i = EPOCH; i < Year; i++)
 !             Julian += 365 + ( (i % 4 == 0) && ((i % 100 != 0) || (i % 400 == 0
 )) );
       } else {
           for (i = Year; i < EPOCH; i++)
 !             Julian -= 365 + ( (i % 4 == 0) && ((i % 100 != 0) || (i % 400 == 0
 )) );
       }
       Julian *= SECSPERDAY;
       Julian += TclDateTimezone * 60L;
 --- 430,439 ----
           Julian += DaysInMonth[i];
       if (Year >= EPOCH) {
           for (i = EPOCH; i < Year; i++)
 !             Julian += 365 + (i % 4 == 0);
       } else {
           for (i = Year; i < EPOCH; i++)
 !             Julian -= 365 + (i % 4 == 0);
       }
       Julian *= SECSPERDAY;
       Julian += TclDateTimezone * 60L;
 $

 PatchFiles:
     generic/tclDate.c

 Comments:
     This is a crucial Y2K issue.  Scriptics's Y2K statement discusses the 2
     digit year issue in great details, but does not address proper leap year
     handling.