[Python-Dev] Epoch and Platform (original) (raw)

Pete Forman pete.forman at westerngeco.com
Wed Jun 18 11:50:59 CEST 2008

"Guido van Rossum" <guido at python.org> writes:

On Tue, Jun 17, 2008 at 11:09 AM, Curt Hagenlocher <curt at hagenlocher.org> wrote:

On Tue, Jun 17, 2008 at 10:56 AM, Guido van Rossum <guido at python.org> wrote:

On Tue, Jun 17, 2008 at 10:40 AM, Curt Hagenlocher <curt at hagenlocher.org> 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 pete.forman at westerngeco.com -./.- the opinion of Schlumberger or http://petef.22web.net -./.- WesternGeco.

More information about the Python-Dev mailing list