<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Aug 16, 2015 at 2:16 PM, Tim Peters <span dir="ltr"><<a href="mailto:tim.peters@gmail.com" target="_blank">tim.peters@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Guido]<br>
> ...<br>
<span class="">> - Would there be any merit in proposing, together with the idea of a<br>
> three-value flag, that datetime arithmetic should use "timeline arithmetic"<br>
> if the flag is defined and a tzinfo is present?<br>
<br>
</span>It's worth considering.  At the highest level, this requires:<br>
<br>
1. Answering whether "timeline arithmetic" does or does not account<br>
for gaps and folds due to leap seconds too.<br>
<br>
2. Supplying a feasible path for those who insist the other answer is<br>
the only acceptable one ;-)<br>
<br>
The way things have gone so far, the current PEP was meant to be a<br>
"baby step" along the way, and PEP 500 goes on to refuse to even ask<br>
#1, instead addressing #2 (tzinfo objects will grow ways to take over<br>
datetime arithmetic, in any damn fool ;-) way they like).<br>
<br>
But if "timeline arithmetic" comes built in, #1 has to be answered up<br>
front - and I wouldn't be surprised then if PEP 500 died, leaving the<br>
#1 "losers" wholly devoid of hope.<br>
<br>
Which I take kinda seriously ;-)<br>
<br>
- It's nuts to add a minute to a UTC datetime and see the seconds<br>
change ("leap seconds are insane").<br>
<br>
- It's also nuts to subtract two UTC datetimes a minute apart and not<br>
get the actual number of seconds between them in the real world ("leap<br>
seconds are vital").<br>
<br>
The advantage of the current approach is that it leaves both camps<br>
equally empowered - and equally challenged - to scratch their own<br>
itches.<br>
<br>
That's the political answer.  As always, I'll leave the tech stuff to<br>
you eggheads ;-)<br>
</blockquote></div><br></div><div class="gmail_extra">How did we end up bending over this far backwards for leap seconds?<br><br>To me, we're talking about a mapping to POSIX timestamps, which use a straightforward algorithm to map compute the date and time -- in particular, divmod(ts, 86400) will give the day number and the second within that day. The day gets converted to a date using standard calendar math (assuming they eventually fix the standard so that 2100 is not considered a leap year :-) and the time gets converted to HH:MM:SS using even simpler calculations. There's no room for leap seconds there.<br><br>It's important to me that if two different Python implementations, running on two different computers, convert a POSIX timestamp to a date+time they get the same result. This is *much* more important to me than the idea that if two computers simultaneously call time.time() they get the same value -- there is simply no such thing as "simultaneously" (imagine one of the computers is on a rocket traveling to the moon).<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">If you care about leap seconds you should use a different time source, and you shouldn't be using either the time module or the datetime module. They are inextricably linked.<br><br></div><div class="gmail_extra">So there's my answer to #1. You may consider this a Pronouncement if you wish. It should not come as any surprise.<br><br>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.<br><br></div><div class="gmail_extra">As for how to request timeline arithmetic vs. the other kind ("human"? I forget where our glossary is), that could be done by special-casing in the datetime class using some property (yet to be determined) of the tzinfo subclass or instance; or it could be done using different timedelta-ish classes. PEP 500 seems overly general just so it can also support the leap second case.<br><br></div><div class="gmail_extra">("So how do I write a real-time stock trading system", you may ask. Good question. Ask the stock exchanges. Their solution was not to trade near the leap second. Given that they probably have to deal with a mix of languages including at least Java, Cobol, Lisp, Python, and Smalltalk, I'm doubtful that they'll do better during the lifetime of Python 3. Famous last words perhaps.)<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>