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

[Chris Barker - NOAA Federal]

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

But naive time is not some arbitrary system unto itself. And while it
is naive about time zones, and has no DST transitions, it is very much
an implementation of a particular calendar system.

And when you add a tzinfo object with methods like utcoffset(), then
you are very strongly implying that it is now UTC. Oh, and
datetime.datetime.utcnow() kind of implies that, too.

The docs do clearly state "no leap seconds" in numerous places. But
nudges like me bring it up enough that maybe a bit more in the docs
would be helpful.

I'll contemplate a doc patch.

-Chris



>
> 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.