Isaac earlier sketched a mathematical framework for a different approach to computing UTC offsets, which explicitly materialized that it's a function made up of a sequence of continuous monotonically increasing functions ("jumps in time" are discontinuities in the range, and that's what separates one function from the next). The start and end of each function's domain is explicit, and so then also are the start and end of each function's image. This makes pretty much all conceivable elementary questions solvable by, at worst, forms of binary search.(e.g.,"is this a missing time", "if so, what's the next closest valid time (in either direction)", "how long until the next transition of any kind?", "how many transitions of any kind occurred in the past 1000 years?" ...).

*Almost* everything can be accomplished with tz.first_transition_after(dt) and tz.last_transition_at_or_before(dt) returning appropriate (trans_utc, before_info, after_info) tuples, but not quite. But yes, I think it would be valuable to expose the transition times in some way, though preferably not as a list since that would preclude POSIX-style time zones (which have an infinite number of such transitions). Does anyone else have a better idea for this API?

But it's far more general than needed for any real-world time zone - and there's no code for that either ;-)

Not yet. I had finally gotten to work on it and realized that the API I was going to propose was insufficient to the task. ijs