Awhile ago, someone brought up the fact that Australian timezones were not options in the locale object; I also mentioned that the locale database thought that en_US and en_AU (all en_*, in fact) included Tokyo and Casablanca. I looked at the ICU information, and they suggested that developers use the Olson information.

Stuart Bishop exposed an appropriate API in his newest release, so now it is possible to follow the ICU advice. I started to look at how to incorporate the new capabilities into the locale object.

After a bit of reflection and discussion here, I'm going to leave i18n locale alone, since it is so clearly defined by the ICU database. Muddying it up with calls to pytz on the basis of country, with values that won't have the same structure as the ICU database entries, would be a problematic change on a number of levels.

So the plan will be to suggest that developers use the pytz information if the locale id has a country code, and otherwise fall back to the locale timezone information. We should generate a .po file for the pytz timezone names so that they can be translated, if desired.

So the only work to be done now is to merge Stuart's work into 3.1, so that the problem identified yesterday is fixed, and so that the new capabilities of pytz are available. I don't plan to make any changes to i18n locales.

Zope3-dev mailing list

Reply via email to