"Guido van Rossum" <[EMAIL PROTECTED]> writes: > On Tue, Jun 17, 2008 at 11:09 AM, Curt Hagenlocher > <[EMAIL PROTECTED]> wrote: >> On Tue, Jun 17, 2008 at 10:56 AM, Guido van Rossum >> <[EMAIL PROTECTED]> wrote: >>> On Tue, Jun 17, 2008 at 10:40 AM, Curt Hagenlocher >>> <[EMAIL PROTECTED]> wrote: >>>> >>>> There's no real urgency. The reason this came up is because I >>>> just implemented zlib, which automatically enabled the gzip unit >>>> tests. The gzip tests are failing because the current timestamp >>>> can't be written as a 32-bit value. >>> >>> Why is that? Is it because your epoch is different? If so, I would >>> much prefer the epoch to be 1970. (Maybe this is the resolution >>> you're seeking?) >> >> Yes! Except that I was hoping for something a little stronger, like >> "the epoch must be 1970" or "the epoch can be anything you want, but >> you're utterly retarded if you pick something other than 1970". But >> I'll definitely settle for "much prefer". :) > > I could go with the "utterly retarded" wording. :-)
The POSIX (UNIX) rules for handling time are laid out clearly. Not everyone is happy with how leap seconds work but at least they can be dealt with by those who need to. Most people will use local time or UTC and other time scales are possible with a bit of effort. If you were to allow an epoch earlier than 1970 then ambiguity is more likely to sneak in. Another reason not to allow an epoch of 1900 is that Microsoft introduced a bug in its leap year algorithm in Excel. The better (less bad) way of using that epoch is to propagate that bug. According to the Pythonic way you should not have to look before you leap. ;-) +1 for strengthening the definition of epoch in the time module to 1970-01-01T00:00:00Z for all platforms. -- Pete Forman -./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED] -./\.- the opinion of Schlumberger or http://petef.22web.net -./\.- WesternGeco. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
