Time Zone Localizations

[Masayoshi Okutsu]

Chuck Soper wrote:

> Are these tables informational or vital to the process? For example, 
> will the Aliases table be used to "Canonicalize the Olson ID" (step 1 
> of the Fallback procedure)? If so, then the table should be based on 
> the current time zone data files instead of "current Java data". This 
> could turn into a serious maintenance issue. Ideally, I think that a 
> script could be run on the time zone data files to generate a new 
> aliases table each time the time zone data files are updated 
> (currently tzdata2004a).

I agree. And it's unclear what the "current Java data" is. *My* current 
Java data is tzdata2004a, which is very unlikely to be shipped with 1.5...

> Where did AET (line 2, Aliases table) for Australia/Sydney come from? 
> I can't find any reference to it in tzdata2004a.

I guess it came from JDK1.1 compatibility names. Someone (not me!) 
invented 3-letter time zone IDs in JDK 1.1, which failed to support more 
time zones. Java uses the Olson zone IDs since 1.2. But we still have 
the JDK 1.1 compatibility names as far as they don't conflict with any 
Olson zone IDs.

> ### Equivalent Modern Zones
> My first reaction whenever I see a significant effort to simplify 
> something for the user is to think that it could lead to problems.

I tend to agree with you. I think we should find out another way to 
reduce the number of localized time zone name strings.

> How did you determine that "A lot of people just don't care about 
> historic differences"? Do most people use time zones merely to keep 
> track of the current time or current differences between another time 
> zone? How else do users use time zones?

Right. And how can we define "current" for time zones which change their 
offsets some time in the future, like America/Mendoza in tzdata2004a? 
The day after tomorrow...? :-)

Masayoshi