Paolo Bonzini wrote: >> --- - 2009-09-14 14:32:58.934253776 +0200 >> +++ in 2009-09-14 14:32:58.930840392 +0200 >> @@ -1,6 +1,6 @@ >> -12131415.16 13 1260713716 Sun Dec 13 14:15:16 2009 >> -12131415.16 13 1260713716 Sun Dec 13 14:15:16 2009 >> -000001010000.00 13 -62167219200 Sat Jan 1 00:00:00 0 >> +12131415.16 13 1039788916 Fri Dec 13 14:15:16 2002 >> +12131415.16 13 1039788916 Fri Dec 13 14:15:16 2002 >> +000001010000.00 13 -62167132800 Sun Jan 1 00:00:00 0000 >> 190112132045.52 13 -2147483648 Fri Dec 13 20:45:52 1901 >> 190112132045.53 13 -2147483647 Fri Dec 13 20:45:53 1901 >> 190112132046.52 13 -2147483588 Fri Dec 13 20:46:52 1901 >> >> Note that the first two differences are to be expected. >> Those tests pass only if 2002 is the current year. >> However, I don't know about the difference in the 3rd line. >> Note the s/Sat/Sun/ change. The new number of seconds is 86400 >> larger than the old one; that's exactly one day's worth of seconds, >> and hence in line with the Sat/Sun change. >> >> I don't yet know if this change is a problem in mktime or due >> to some intervening fix. > > cal accepts only years from 1 to 9999, but anyway it implements the > Julian calendar correctly so it is not useful (you really should try > "cal 9 1752"!!).
Ouch ;-) > Going backwards from "cal 1 1" you can see that in > the Julian calendar 01-Jan-0000 was a Thursday, but that's not so > relevant. > > However cal can help seeing that 01-Jan-0000 is a Saturday in > Gregorian proleptic calendar (i.e. extending Gregorian calendar before > the day when it was adopted). 400 years have 146097 days, which is > divisible by 7, and 01-Jan-2000 was a Saturday. If that's true, then this new test failure suggests there's a bug in mktime.
