Leap seconds? Leap seconds aren't supposed to exist when looking at POSIX timestamps. They don't exist when I look at my watch either, and that's what I expect from any time-keeping device except those for use by astronomers.
On Wed, Jun 18, 2008 at 2:50 AM, Pete Forman <[EMAIL PROTECTED]> wrote: > "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/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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