[Datetime-SIG] Fwd: Calendar vs timespan calculations...

[Tim Peters]

[Tim]
>> Sorry about this.  I don't want to talk about leap seconds anymore,

[Chris Barker]
> Nor do I, but ...

Python isn't going to support leap seconds out of the box.  We
(primarily meaning Alexander) _are_ trying to make it possible for
someone who wants to supply an external implementation to do so, but
that's not going to drive any current decision.

> ...
> Exactly. So for now, we simply document that Naive time IS TAI time,

But it's not.  You're free to think of a naive datetime as
representing a TAI time if you like, but that's as far it goes.  You
are, e.g., equally free to think of it as being a GPS time.  That's up
to you (TAI and GPS time both fit Python's naive time model - but so
does "Tim's personal time", which has nothing to do with durations in
SI seconds).

For the rest, this is the high-order bit:

> ...
> This is uglier than it should be because a lot (most?) time libraries don't
> do leap seconds,

Can you name one that does?  Not a single one has been mentioned in
this entire mountain of messages so far (that I saw).  Even Common
LISP, which can usually be counted on to be as anal as conceivable ;-)
, ignores leap seconds.

Which is a primary reason Python will always ignore them too:  it
makes Python's core calculations compatible with every other
programming language's on Earth.

If you need surprise-free durations in SI seconds, use TAI.  If your
colleagues create a Tower of Babel, each using their own definition of
time, that's far more a social problem than a technical one.  Agree on
a standard, and - poof! - no more communication or conversion problems
in this area - and if you pick TAI, the intended meaning of the data
will remain clear until the last human dies ;-)

There are ways to get at "real UTC" (and TAI, and UT1, and ...) from
Python now, but they're in specialized packages few people know about.
That's appropriate, because few people actually need them.  They would
confuse people who don't need them.  For example, just try to picture
99.997% of users trying to make sense of the astropy docs:

    http://astropy.readthedocs.org/en/stable/time/index.html

    The astropy.time package provides functionality for manipulating
    times and dates. Specific emphasis is placed on supporting
    time scales (e.g. UTC, TAI, UT1, TDB) and time
    representations (e.g. JD, MJD, ISO 8601) that are used in
    astronomy and required to calculate, e.g., sidereal times and
    barycentric corrections.

It's wonderful that such packages exist, but they don't belong in the core.