Gary Poster wrote:

>>> And FWIW, once you get your browser settings correct, for the
>>> timezone part of the locale database, en-* is all the same--that is,
>>> if my locale is en-US, I get all en* locations (including Casablanca,
>>> Tokyo, and other interesting locations). :-)  I think you will too.

> You know, I was about to write back and say, hey, don't blame us,  it's
> those crazy Unicode people: main/
> .  We are using their database.
> Then, when I was looking up how to submit bug reports to the  database,
> I saw this on filing_bug_reports.html :
> """Similarly, the timezones for different  regions are to be derived
> from Olson data, and are not in the locale  data.""".
> It seems we are supposed to be getting our i18n timezone data,  mapping
> country code to timezone name, from the Olson database.  AU,  for
> instance, gets this much more reasonable list from the current  Olson
> database's '' file:
> AU      -3133+15905     Australia/Lord_Howe     Lord Howe Island
> AU      -4253+14719     Australia/Hobart        Tasmania - most  locations

> Stephan, do you have any concerns about incorporating the Olson 
> information in 18n?  I suppose another approach would be to see if 
> Stuart would be willing to have pytz grow this mapping, and have the 
> i18n package depend on pytz.  I'd actually prefer that, if you and 
> Stuart agreed and were willing, since he already has his automatic 
> processing of the Olson database, and is already keeping up with the 
> Olson releases.

I'm happy to expose this through pytz. There is a new set of data files
released yesterday (including the 2006 changes the US has just signed into
law) so I can push out a new release in the next day or two with this added.

Stephan - Should this update go into the 3.1 branch, or just the trunk?

Stuart Bishop <[EMAIL PROTECTED]>

Attachment: signature.asc
Description: OpenPGP digital signature

Zope3-dev mailing list

Reply via email to