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/)