[Datetime-SIG] PEP 495: What's left to resolve
Tim Peters
tim.peters at gmail.com
Wed Sep 9 04:10:49 CEST 2015
[Alex]
>> Definitions: An aware datetime value t is called "regular" if t.utcoffset()
>> does not depend on the value of the fold attribute.
[Chris Angelico]
> One point to clarify here. Is the definition of "regular" based on the
> timezone alone (that is to say, a UTC datetime is regular, and an
> Australia/Brisbane datetime is regular, but anything in a region with
> DST is always special), or are "special" datetimes only those in the
> fold period?
It applies to "an aware datetime value t". That's clear already ;-)
Everything about `t` matters. In plain English `t` is "regular" if
and only if `t` is in neither a fold nor a gap. So, e.g., all `t` in
UTC are regular. In most zones with a notion of DST, there are
exactly 2 wall-clock hours per year that are not regular (in the gap
at the start of DST, and in the fold at DST end).
> The former is easily identified. As the zoneinfo file is parsed, it'll
> be obvious which ones can ever have times that differ only in fold,
> and they get flagged as "special". The check is simple - ask the
> timezone object whether it's regular or special.
What's actually needed isn't that simple.
> The latter, perhaps not so much. Given a particular datetime, can you
> easily and reliably ascertain whether or not there is any other
> section of time which can "look like" this one?
Impossible to answer "easily" without knowing all the details of a
specific tzinfo's internal data representation.
For, e.g., a timezone _defined_ by a POSIX TZ rule, it's trivial,
since those explicitly spell out the "problem hours" as local
wall-clock times.
For a tzfile, I posted pseudo-code a while back showing how to
determine whether a UTC time corresponds to a fold in the zone, using
a few simple calculations after doing a binary search across the
zone's transition list to locate where the input UTC time belongs. A
fold exists if and only if the current total UTC offset is less than
the previous transition's total UTC offset. The opposite for a gap.
However, this may mishandle cases (if any exist - I don't know) where
consecutive transitions have exactly the same total UTC offset.
So there are details left to flesh out, but it's conceptually easy enough ;-)
For other zone sources, who knows?
More information about the Datetime-SIG
mailing list