[Python-Dev] Status on PEP-431 Timezones

[Isaac Schwabacher]

On 15-04-09, Alexander Belopolsky  wrote:
> 
> On Thu, Apr 9, 2015 at 3:39 PM, Isaac Schwabacher <ischwabacher at wisc.edu(javascript:main.compose()> 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?

PEP 431 proposes to import zoneinfo into the stdlib, so there will be a standard way to get this information. That's kind of the whole point. But there's really no good cross-platform way to get the name of the system time zone. tzlocal figures out what it is for certain classes of systems for which it's possible, and is also being proposed for stdlib inclusion in the PEP.

> 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.

This functionality should probably be exposed (in ruby it's TZInfo::TimeZone#periods_for_local, where TZInfo is an external package; I don't think it's easily available in pytz), but if it's the default way to do a conversion, I suspect that it's more likely to just lead to poor error reporting.

ijs