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

Alex Lord AlexMLord at gmail.com
Thu Apr 9 02:11:50 CEST 2015

Newb question time, what's BoF

On Wed, Apr 8, 2015 at 7:31 PM, Alexander Belopolsky < alexander.belopolsky at gmail.com> wrote:

On Wed, Apr 8, 2015 at 6:52 PM, Isaac Schwabacher <ischwabacher at wisc.edu> wrote: > > > So "storing the offset" and "storing a flag" are not two alternative solutions to the same problem- these > > are two solutions to two different problems. > > I'm viewing a time zone as a map from UTC to local time; for example, America/Chicago is a time zone. I'm not proposing storing the offset as an alternative to storing the time zone, I'm proposing it as an alternative to storing whether a given time is DST or not.

When you are proposing to store something, you also need to specify where you are proposing to store it. In the current design, local time information is stored in the datetime object and the rules that govern UTC to local mapping (and back) are stored in the tzinfo object. The implementors of concrete tzinfo subclasses are supposed to have access to time zone rules and implement utcoffset(dt), together with dst(dt) and tzname(dt) methods. Storing isdst in the datetime object would allow utcoffset(dt) to distinguish between 1:30AM before clock change and 1:30AM after. Where do you propose to store the offset? If you store it in dt, why would you need the tzinfo? > > We really don't care whether a time is DST or not; You may not care about it, but current tzinfo interface and tzinfo.fromutc(dt) method do. Whatever new features are added to the standard library, they cannot break existing uses. This means that whatever concrete tzinfo implementations we add to stdlib, they must provide an implementation of tzinfo.dst(dt) method. > So our times would look like "2013-11-03 01:30:00-0500 America/Chicago" and an hour later, "2013-11-03 01:30:00-0600 America/Chicago". And all of that information is stored in the datetime object. I don't think this is what most people would expect $ TZ=America/Chicago date Wed Apr 8 18:26:01 CDT 2015 or $ TZ=America/Chicago date +"%c %z" Wed 08 Apr 2015 06:27:09 PM CDT -0500 and not have location as a part of their timestamps. Regardless, whatever the proposal to add timezones to stdlib will end up being, it must include the ability to implement an equivalent of UNIX date command shown above.

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/alexmlord%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150408/079aebb4/attachment.html>

More information about the Python-Dev mailing list