[Datetime-SIG] PEP-431/495

Chris Barker 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
tzinfo instance?

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
somewhere now?

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?


>  gaps

> & 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...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150822/1044e0f1/attachment.html>

More information about the Datetime-SIG mailing list