On Mon, Aug 17, 2015 at 1:46 PM, Alexander Belopolsky < [email protected]> wrote:
> On Mon, Aug 17, 2015 at 3:05 PM, Guido van Rossum <[email protected]> > wrote: > > On Sun, Aug 16, 2015 at 9:10 PM, Tim Peters <[email protected]> > 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)
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
