[Stuart Bishop] >> ... >> To convert it to a 'first' flag, we need to first parse the datetime, >> determine the transition points that year, and then which side of >> the nearest transition point it lies. Note that there can be more >> than 2 transition points in a year, and no api has been discussed for >> discovering them.
[TIm] > Python doesn't need such an API. Let me be clearer about this. I appreciate that Olson-general timezones are a PITA to implement both compactly and efficiently. tzinfo internals may want all sorts of internal "helper APIs" to ease that burden. The alternative is asking Alexander "and what about this year?" for each annoying case, and waiting for him to write a class implementing the rules for just the specific year in question ;-) Hammering that stuff out is certainly appropriate on this list - it's just not in the scope of PEP 495. That's about specifying visible results (requirements on tzinfo implementations), and adding a user-visible flag requires a PEP. tzinfo internals don't require approval from anyone. In that respect, PEP 500 would have allowed each tzinfo class to implement arithmetic in the most efficient way sufficient for the timezone it represents. But that's been killed. 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). That does allow for one major zone-dependent optimization: if a timezone has a single UTC offset and a single name for all eternity (timezone.utc being the most important example), then .utcoffset(), .dst(), .tzname() and .fromutc() are one-liners, and classic and timeline arithmetic are the same thing. So such zones can (& "should") use a single dirt-simple "I want classic arithmetic" class regardless of the arithmetic bit (for simplicity and efficiency: gaps & folds don't exist in such zones, and classic arithmetic goes much faster than timeline arithmetic). For internal purposes, it _may_ be that a tzinfo wrapping would like to make similar distinctions among other kinds of timezones. For example, it it sees that it's wrapping a zone that's only ever had one base UTC offset, and a single DST rule, it could be modeled by an instance of a tzinfo subclass with code customized to take advantage of those regularities. But all of that is out of scope for 495 too. _______________________________________________ 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/
