[Python-Dev] proposal: add basic time type to the standard library

[Guido van Rossum]

> FYI, mxDateTime test the C lib for leap second support; if leap
> seconds are used, then it has to support these too in conversions
> from and to Unix ticks.

Since AFAIK POSIX doesn't admit the existence of leap seconds, how do
you ask the C library for leap seconds?

> > BTW, I doubt there'd be any discussion of leap seconds in the C
> > std if some astronomers hadn't been early Unix users.  It's never
> > a net win in the end to try to make a scientist happy <0.9 wink>.

Yeah, we learned that the hard way by adding complex numbers. :-)

> What strange about leap seconds is that they don't fit well with
> the idea of counting seconds since some fixed point in history.
> They are only useful for conversions from this count to a broken
> down date and time representation.... time simply doesn't
> leap.
> 
> >From a comment in mxDateTime:
> /* This function checks whether the system uses the POSIX time_t rules
>    (which do not support leap seconds) or a time package with leap
>    second support enabled. Return 1 if it uses POSIX time_t values, 0
>    otherwise.
> 
>    POSIX: 1986-12-31 23:59:59 UTC == 536457599
> 
>    With leap seconds:             == 536457612
> 
>    (since there were 13 leap seconds in the years 1972-1985 according
>    to the tz package available from ftp://elsie.nci.nih.gov/pub/)
> 
> */

I think an important (but so far unvoiced) requirement is that
datetime objects can be stored in a database.  Since the database may
be read by systems that may or may not support leap seconds, we should
be independent of the leap second support in the C library. As I've
said before, we should ignore leap seconds.  Even if we end up
expressing times deltas as a number of seconds, that should be
understood to be calendar seconds and not astronomical seconds.  Let
the astronomers deal with leap seconds themselves -- they should know
how to.

BTW, this means that we can't use the C calls mktime(), timegm(),
localtime(), and gmtime(), or their Python wrappers in the time
module!  That's fine by me.

--Guido van Rossum (home page: http://www.python.org/~guido/)