[Python-Dev] Status on PEP-431 Timezones

[Alex Lord]

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>