[Python-Dev] Draft PEP for time zone support.
regebro at gmail.com
Mon Dec 31 14:17:51 CET 2012
On Sun, Dec 30, 2012 at 11:19 AM, Steven D'Aprano <steve at pearwood.info>wrote:
> If I've understood it correctly, that contradicts the PEP. One example
> given is "Etc/GMT+11", which is not a timezone *name*, but a timezone
> name *plus an offset*. Presumably if GMT+11 is legal, so should be
This depends on your definition of a timezone name. There is no generally
accepted authority for time zone names, the closest one we get is the
zoneinfo database itself, which is maintained by ICANN. It has an
There is no "Etc/GMT+11" named here:
It exists in the database files, http://www.iana.org/time-zones, the
> nor is it included in /usr/share/zoneinfo/zone.tab in either of the systems
zone.tab contains none of the Etc/Something zones.
> I looked at (one Debian, one Centos), but there is Etc/GMT. So I conclude
> that the PEP allows timezone rules, not just names.
This is more problematic, and for that reason I'll change the PEP to use
> Either way, I think the PEP needs to clarify what counts as a valid name
A timezone file that exists in the zoneinfo database used.
Perhaps the database is out-of-date, or the government has suddenly declared
> a daylight savings change that isn't reflected yet in the database. Or you
> want to set your own TZ rules for testing. Or you've just declared
> from the central government and are setting up your own TZ rules.
> time.tzset supports rules as well as names. Is there some reason why this
> module should not do the same?
You will be able to make your own rules, the simplest is probably by adding
it to your zoneinfo database. Doing so is however not trivial, and outside
of the scope of this PEP.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev