> 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
_______________________________________________
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/
