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

[Tim Peters]

[Tim]
>>> Don't add TAI as an alias.  Only a relative handful of people have
>>> ever heard of it.  Among those who both have and care about it, it has
>>> a precisely defined meaning which isn't satisfied at all unless they
>>> _can_ get elapsed SI seconds by subtracting.  That's a primary use
>>> case for TAI.

[Chris Barker]
> Doesn't an implementation of the Proleptic Gregorian Calendar with no
> leap seconds provide that? e.g. the Python datetime implementation?

TAI has more than one "moving piece".  Because _all_ the pieces are
important to the relative handful of people who need TAI, it's highly
misleading to call something "TAI" unless it implements all the
pieces.

Provided you view naive datetimes as expressing times in TAI calendar
notation, then, yes, Python's calendar notation and classic arithmetic
implement those parts of TAI precisely.

But there's no builtin support for any other piece needed to use TAI:

- There's no way to ask "what time is it now?" and get a TAI result
(unless you're on one of the rare rumored Linux variants configured to
use TAI for the system clock), neither in TAI seconds-since-the-epoch
notation nor in TAI calendar notation.

- There's no direct way to ask how a datetime expressed in TAI
calendar notation is expressed as TAI seconds-since-the-epoch
notation.  This is easy to write a function for, though (subtract a
naive datetime expressing the start of the TAI epoch in TAI calendar
notation).  Ditto in the other direction.

- There's no way to use the current timezone implementation to convert
TAI to or from any other time scheme.


> M-A s note made this all a bit more clear to me: business use cases
> are a lot more concerned with the Calendar than actual elapsed time.

Even worse, businesses generally want _not_ to see actual elapsed
time.  For example, you rent a car for a week, at $300/week plus $50
for every hour over.  You pick it up at the airport at 11am Saturday,
hand over $300, and return it by 11am the following Saturday.  They
demand you pay an extra $50, because DST ended the day after you
picked it up.  Heh - that's a great way to ensure you never rent from
them again ;-)

> On the other hand, I do scientific applications, and am far more
> concerned with accurate elapsed time.
>
> And yes, most code uses an internal time representation in integer
> seconds, or the like.
>
> But we still have to deal with input and output in human-friendly
> time. And for that, python's datetime is very, very useful. And
> primarily because it does a good job with 'strict' timedeltas.

In the language we seem to have settled on, timedelta does "classic
arithmetic" now, and how it _would_ work if it _did_ account for
things like DST transitions is called "strict" or "timeline"
arithmetic.


> In fact, given that integer units of time are the most natural, the
> primary use of python's datetime that I've seen is to convert to-from
> a "timespan since an epoch" representation, which requires proper
> timespan computation.

I don't see how that could be a primary use now, since Python's
datetime arithmetic now doesn't do "proper timespan computation" (as I
believe you mean it) in any time zone defined as an offset (including
0) from real-life UTC.

You can't do it using POSIX seconds-from-the-epoch timestamps either
(not directly; you would need additional code to account for leap
second adjustments across the span of interest).


> (And a lot of the data I've seen is based on poor choices of epoch,
> unfortunately)

Social problem:  nag them ;-)


> So my entire point here is that it's great to preserve and enhance
> that capability, and leave the door open to future enhancements. And
> Alexander's work looks like it's going in the right direction.
>
> Thanks for indulging me -- I, at least, learned a lot.

I just hope some of it finds some actual use ;-)  Have you read this
yet?  It explains a lot.

    https://en.wikipedia.org/wiki/Unix_time