[Datetime-SIG] Trivial vs easy: .utcoffset()

[Tim Peters]

[Tim[
> I haven't stared at mktime() in anger.  Is there anything it could be
> _told_ about the local zone that could ease its job?  ...

Easy idea:  after loading a tzfile, create and store (on the tzinfo
instance) a list of every unique total UTC offset in the zone's
history, ordered by most recent to least.  .utcoffset() then only
needs to march through that list once, seeing whether the input minus
the current offset (from the list) converts back to the input via
.fromutc().  If none do, that's an internal error.

That should usually get out in one or two tries (the zone's most
recent "standard" and "daylight" total offsets, in some order, will
usually be tried first).  For historical dates, who cares - they're
only going to appear in test cases anyway, and even then can't require
.more .fromutc() calls than there are unique UTC offsets in the zone's
history.

For zones entirely defined by a POSIX TZ rule, the list would contain
at most two entries.

Nailed it ;-)

Pickles are always a puzzle.  The list of unique offsets may well
change in the future, so it should really be recomputed from scratch
when unpickling.