[Zope3-dev] plan to address the i18n locale timezone problem

Gary Poster gary at zope.com
Wed Sep 7 11:08:58 EDT 2005


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.

Gary


More information about the Zope3-dev mailing list