tim.peters at gmail.com
Sun Aug 23 00:28:32 CEST 2015
>> What we're left with
>> appears to be just one other bit, spelled via the presence or absence
>> of a new magic attribute on a tzinfo instance, or via inheritance or
>> non-inheritance from a new marker class. That new bit is used to
>> spell "classic or timeline arithmetic?" (which datetime internals -
>> not tzinfos - will be required to implement).
[Chris Barker <chris.barker at noaa.gov>]
> if it would be implemented by datetime, or a datetime subclass, wouldn't it
> make sense for that attribute to be on the datetime instance, rather than a
> tzinfo instance?
Which is why arithmetic "belongs in" tzinfo too - how the local clock
acts is entirely about the timezone. But, given that we're not going
to do it that way, Guido already answered (to you!) why it's better to
put the arithmetic flag in a tzinfo.: datetimes are created all over
the place and by all kinds of operations, but a program typically only
has a few places where it invokes a factory function to get a tzinfo
instance. It's not credible that people will want to switch
arithmetic on a datetime-by-datetime basis; it's entirely credible
that they want all datetimes with a given tzinfo to use the same kind
of arithmetic. So putting the flag on the tzinfo makes what everyone
wants dead easy to do, at the cost of making things nobody wants to do
> so is it time to add an attribute to specify "timeline" arithmetic somewhere
No. And I won't discuss it more. If you want to push it, get Guido
to insist on it ;-)
> BTW, as I read it, PEP 431's biggest contribution was to bring access to a
> timezone database into the stdlib -- is that idea dead?
No, but it's not in PEP 495. It's not in any active PEP at the
moment. But since Stuart Bishop is here now, and he wrote pytz, I
don't expect that to last ;-)
>> & folds don't exist in such zones, and classic arithmetic goes much
>> faster than timeline arithmetic).
> much faster?
Yes. At least factor-of-10 faster. Alexander recently posted code
showing that, and it's not at all surprising.
> isn't it "just a "convert to UTC, do the math, convert back to the TZ?"
Which are far more expensive than you might guess. Spend some time
staring at "the rules" in the Olson database. They're a god-awful
irregular mess. Each conversion has to take into account an
arbitrarily long list of historical base-offset changes, then from
that find the current DST rules in effect, and from that do irregular
calendar calculations like "second Sunday in March" to figure out when
DST begins and ends in the current year (and even those may occur more
often than _just_ once per year).
Alexander got his results from "timeline arithmetic" that was utterly
trivial compared to all that, just the extra expense of some doing
some semantically useless +/- timedelta(0) operations. I wouldn't be
surprised to see timeline arithmetic approaching being 100 times
slower for a timezone that's full of historical baggage.
> and for the "simple" TZs, the convert is an addition or subtraction.
Only if they're implemented to take advantage of the simplifications
that are possible. Which only a tzinfo implementer can know.
> Is it worth optimizing that out?
Not to me, because I have no use for builtin timeline arithmetic at
all, But I bet _you'd_ complain about it ;-)
> Though I suppose that if the only thing you need to do to optimize it is
> for the tzinfo class to be responsible for that decision, then maybe that
> is a fine argument for putting that decision there.
Only a tzinfo author has any idea how a timezone works at a high
level. All the _user_ of a tzinfo can know is the UTC offset at some
particular microsecond in local time (& similarly microscopic things
of no use for optimization).
More information about the Datetime-SIG