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