[Python-Dev] Status on PEP-431 Timezones (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Fri Apr 10 12:12:02 CEST 2015

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>

More information about the Python-Dev mailing list