On Sun, Dec 30, 2012 at 11:19 AM, Steven D'Aprano
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_zoneshttp://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