chris.barker at noaa.gov
Sat Aug 22 23:46:43 CEST 2015
On Sat, Aug 22, 2015 at 11:55 AM, Tim Peters <tim.peters at gmail.com> wrote:
> 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).
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
Anyway, I have an interest in seeing that done -- and Alexander is right,
it would be better to make whatever changes we need to datetime now in a
way that will last.
so is it time to add an attribute to specify "timeline" arithmetic
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?
> & folds don't exist in such zones, and classic arithmetic goes much
> faster than timeline arithmetic).
much faster? isn't it "just a "convert to UTC, do the math, convert back to
the TZ?" and for the "simple" TZs, the convert is an addition or
subtraction. Is it worth optimizing that out? 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.
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Datetime-SIG