[Python-Dev] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Thu, Apr 9, 2015 at 3:39 PM, Isaac Schwabacher <ischwabacher at wisc.edu>
wrote:

> > Well, you are right, but at least we do have a localtime utility hidden
> in the email package:
> >
> >
> > >>> from datetime import *
> > >>> from email.utils import localtime
> > >>> print(localtime(datetime.now()))
> > 2015-04-09 15:19:12.840000-04:00
> >
> >
> > You can read <http://bugs.python.org/issue9527> for the reasons it did
> not make into datetime.
>
> But that's restricted to the system time zone. Nothing good ever comes
> from the system time zone...


Let's solve one problem at a time.  You cannot have a complete TZ support
without supporting the local timezone.  The advantage of starting with the
local timezone is that most systems have a semi-standard interface to
obtain local zone name and offset for any UTC time.  To support multiple
zones, one would
need to bundle an external library which opens a lot of questions that are
orthogonal to the issue at hand:
how to deal with ambiguous local times in the presence of DST or other
political time shifts?

email.utils.localtime solves this problem in the same way as POSIX mktime
does: by introducing an optional isdst flag.  The main objection to this
interface was that in most use cases the programmer has no intelligent way
to set this flag to anything other than -1.

An alternative solution would be to have localtime(dt) (or astimezone(dt))
return a list of aware local times that in most cases will contain only one
element, but may contain 0 or 2 when dt falls on a switchover.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150409/6e2eeac6/attachment.html>