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

[Guido van Rossum]

On Mon, Aug 17, 2015 at 1:46 PM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

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

Fine.


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

Well, everyone implementing a tzinfo class will be confronted with the
question whether to provide those special methods or not. And they may well
be copy/pasting code that implements them. So my claim is that this makes
the life of everyone implementing a tzinfo a little more complex, not just
that of tzinfo implementers who actually need this protocol. Just like the
mere existence of __length_hint__ serves as a distraction for anyone
implementing an iterator.


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


Why not centuries? FWIW, Dropbox did something similar for the most recent
leap second.


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

Let's put this in perspective though. A second per day is close to an
astonishing 0.001% accuracy. Measuring time can be done with insane
accuracy compared to most other physical quantities, and for some
scientists, that accuracy is not enough. But I still think the effort spent
discussing it is out of proportion. Instead of PEP 500, people who care can
write their own library. Being able to redefine the meaning of a+b to
support such an esoteric case seems unnecessary -- they can just write
their own add(a, b) function.


>
> >>
> >> > 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 don't buy that it's necessary to be able to use the + operator for this.
I *may* accept that it's necessary to be able to parse ISO 8601 (-like)
formats that include leap seconds. And I may even accept that a datetime
instance with tzinfo is a better return value of such a parse call than a
tuple. But I still believe that the use case is esoteric enough that the
parsing method should be given a special flag to allow seconds==60.

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

That's a straw man, right? The stock markets closed around the leap second
because they can't deal with this.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150817/fc963553/attachment-0001.html>