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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
