[Datetime-SIG] PEP-431/495

[Tim Peters]

[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.