[Datetime-SIG] PEP-0500 (Alternative datetime arithmetic) Was: PEP 495 ... is ready ...

[Alexander Belopolsky]

On Mon, Aug 17, 2015 at 3:05 PM, Guido van Rossum <guido at python.org> wrote:
> On Sun, Aug 16, 2015 at 9:10 PM, Tim Peters <tim.peters at gmail.com> wrote:
..
>> Eh - I don't see that we are.  The `first` flag is applicable to any
>> source of folds and gaps, provided the folds aren't worse than 2-to-1.
>> Leap seconds are just one more case of that.
>
>
> That was in reference to PEP 500 more than to the `first` flag.

Changing the subject accordingly.

>
>>
>> If you want to build in gap-and-fold-aware arithmetic, then it seems
>> only one kind can be supported.  If it's left to tzinfo implementers,
>> then it's up to them.
>
>
> Well, most tzinfo implementers have other priorities; leap-secondists, while
> loud, are rare enough that the extra freedom just complexificates the API
> for everyone else without reason.
>

I don't see how PEP-0500 affects anyone other than implementers of
exotic tzinfo implementations.   Regular users will just need to pick
between subclassing datetime.tzinfo  and get "human" arithmetic within
their timezone or subclass tzstrict to get "strict" arithmetic.  Most
user will not even need that because their vendor of tzinfo
implementations will have made the choice for them.

..
>> The remaining question is whether you want to make it impossible for
>> someone else to add it.
>
>
> That depends on the cost for everyone else. If the cost is PEP 500, that's
> too high a price.
>

It is unlikely that leap seconds will disappear from the definition of
UTC.  It is likely that something like Google's "leap smear" will
become the best practice to be followed for years (if not decades) to
come.  Doing real-time calculations on the data recorded by a computer
with a leap-smeared time source is even harder than on the data with
true UTC timestamps.  Nevertheless,  PEP-0500 will enable someone to
implement a "leap_smear_tzinfo" class and have datetime arithmetics
that knows that some 1000 seconds in a given day are more equal than
others.

>>
>> > And while I'm at it, I don't think PEP 500 is the answer. If you really
>> > want
>> > the number of real-world seconds between two datetime values you can
>> > write
>> > your own difftime() function that consults a leap seconds database.
>>
>> That's a start.  Related questions include "the nuclear reactor has to
>> be vented exactly 3600 SI seconds from now - what will the local clock
>> say then?".
>
>
> They should probably use their own clock hardware and software rather than
> use time.time().
>

PEP-0500 is not about time sources or time counters.  It is the answer
to a seemingly simple question:  how many seconds have passed from
<d>T12:00 to <d+1>T12:00.  The answer depends on your definition of
12:00.  If you define 12:00 as the time when the gnomon shadow passes
the noon tick on the city clock tower, then the answer will be
different every day.  If you use a "coordinated" time scale, then the
answer will be different every few years.   If you are sophisticated
enough that your time source delivers meaningful nanoseconds - you
probably need to consult the tide table for your area to to know the
true distance between your time source ticks. Nevertheless, if the
recorded timestamps appear in your data in ISO 8601 - like format,
someone could write a PEP-0500 tzinfo implementation that would let
you manipulate your timestamps as any other datetime instances.

>>
>> I agree such apps "should be" using TAI.  But the one actual scientist
>> who has posted here most often says they don't get a choice about the
>> time system used by the data they need to analyze.  I say they should
>> convert all the data they're given to TAI.  They don't want to hear
>> that ;-)
>
>
> But what does their data look like? And what time source originally
> generated it (and how does that time source handle leap seconds)? It also
> makes a big difference what kind of intervals they are looking at.
>

Suppose you are the market regulator looking at the trades from two traders:

Trader A   Trader B
23:59:59.01   23:59:59.30
23:59:59.40   23:59:59.45
23:59:60.00   23:59:59.40

Did trader B place his last trade before trader A did?  A $100M
lawsuit outcome depends on your answer!  There is probably enough
information in the evidence to conclude that Trader A printed UTC
timestamps and Trader B was POSIX compliant and repeated the 23:59:59
second.  You can get their ntpd logs and interview their system
administrators, but at the end of the day - wouldn't it be nice to use
Python to analyze all that data and win your case with a simple
dta.replace(tzinfo=TraderA) < dtb.replace(tzinfo=TraderB)?