[Datetime-SIG] PEP 495 (Local Time Disambiguation) is ready for pronouncement
Guido van Rossum
guido at python.org
Mon Aug 17 04:29:54 CEST 2015
On Sun, Aug 16, 2015 at 2:16 PM, Tim Peters <tim.peters at gmail.com> wrote:
> > ...
> > - Would there be any merit in proposing, together with the idea of a
> > three-value flag, that datetime arithmetic should use "timeline
> > if the flag is defined and a tzinfo is present?
> It's worth considering. At the highest level, this requires:
> 1. Answering whether "timeline arithmetic" does or does not account
> for gaps and folds due to leap seconds too.
> 2. Supplying a feasible path for those who insist the other answer is
> the only acceptable one ;-)
> The way things have gone so far, the current PEP was meant to be a
> "baby step" along the way, and PEP 500 goes on to refuse to even ask
> #1, instead addressing #2 (tzinfo objects will grow ways to take over
> datetime arithmetic, in any damn fool ;-) way they like).
> But if "timeline arithmetic" comes built in, #1 has to be answered up
> front - and I wouldn't be surprised then if PEP 500 died, leaving the
> #1 "losers" wholly devoid of hope.
> Which I take kinda seriously ;-)
> - It's nuts to add a minute to a UTC datetime and see the seconds
> change ("leap seconds are insane").
> - It's also nuts to subtract two UTC datetimes a minute apart and not
> get the actual number of seconds between them in the real world ("leap
> seconds are vital").
> The advantage of the current approach is that it leaves both camps
> equally empowered - and equally challenged - to scratch their own
> That's the political answer. As always, I'll leave the tech stuff to
> you eggheads ;-)
How did we end up bending over this far backwards for leap seconds?
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.
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).
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.
So there's my answer to #1. You may consider this a Pronouncement if you
wish. It should not come as any surprise.
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.
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
("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
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Datetime-SIG