[Datetime-SIG] PEP 495: What's left to resolve

[Tim Peters]

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