On Sat, Aug 22, 2015 at 11:55 AM, Tim Peters <[email protected]> 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? -Chris > 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. -Chris -- Christopher Barker, Ph.D. Oceanographer 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 [email protected]
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
