[Python-Dev] Status on PEP-431 Timezones

[Nick Coghlan]

On 9 Apr 2015 16:41, "Isaac Schwabacher" <ischwabacher at wisc.edu> wrote:

> I'm suggesting an internal representation, not a user interface. The only
user-facing consequence of this internal representation would be exposing
the offset to datetime.replace() and as a field on the object. All of the
other interfaces that convert naive datetimes into aware datetimes would
still use the is_dst flag as specified in the PEP. The intention is to make
it easy to implement arithmetic and things like relative timedeltas.
>
> But looking at datetime.h, which seems to be willing to sacrifice
conceptual simplicity in order to pack a datetime into as few bytes in
memory as possible, it seems like whatever made that a good idea makes this
a bad one. :/

The question of "store the DST flag" vs "store the offset" is essentially a
data normalisation one - there's only a single bit of additional
information actually needed (whether the time is DST or not in the annual
hour of ambiguity), which can then be combined with the local time, the
location and the zone info database to get the *actual* offset.

The developer facing API should thus focus on letting developers provide
that additional bit of information needed to query the zone info database
correctly.

Caching the result of the database zone offset lookup on the instance may
be useful as a speed optimisation (at the cost of additional memory usage
per instance), but that difference should be quantified before introducing
the redundancy, rather than being assumed to be necessary.

As an internal space/speed trade-off it's also not a decision that needs to
be made as part of the PEP discussion - the external API will be the same
regardless of whether or not the offset is cached after looking it up from
the zone info database.

A question the PEP perhaps *should* consider is whether or not to offer an
API allowing datetime objects to be built from a naive datetime, a fixed
offset and a location, throwing NonExistentTimeError if the given date,
time and offset doesn't match either the DST or non-DST times at that
location.

Cheers,
Nick.

P.S. The description of NonExistentTimeError in the PEP doesn't seem quite
right, as it currently says it will only be thrown if "is_dst=None", which
seems like a copy and paste error from the definition of AmbiguousTimeError.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150410/8060ff13/attachment.html>