[Python-Dev] Epoch and Platform

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