[Datetime-SIG] Calendar vs timespan calculations...
ISAAC J SCHWABACHER
ischwabacher at wisc.edu
Sat Aug 1 15:41:34 CEST 2015
> 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.
More information about the Datetime-SIG