(original) (raw)

On Sun, Dec 30, 2012 at 11:19 AM, Steven D'Aprano <steve@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
GMT+10:30.

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 Etc/GMT+11.

There is no "Etc/GMT+11" named here:

http://en.wikipedia.org/wiki/List_of_tz_database_time_zones

It exists in the database files, http://www.iana.org/time-zones, the ``etcetera`` file.

�

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 another example.
�

Either way, I think the PEP needs to clarify what counts as a valid name

string.

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 independence

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.

//Lennart