RE: Zone Localizations

Mark,

> We are planning to make some changes in the way we handle time zone
> localizations in ICU 2.8. We would welcome comments on the following
> design document:
> 
> http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/gmt_translations.html

You like challenges.

"while many programmers may be familiar with it, end users may not be familiar with "GMT", or may not want to 'do the math'. " 

If a user in California sees "3:00 PM New Delhi Time" then he/she will have to get out the atlas to find the time zone and probably not know if it is DST or not and be very confused and not be able to do the math. (The same would apply to "Asia/Calcutta".) If it is an application where it is essential that the times all be locale times then a user will see local times from all over the world then they will probably know GMT and using GMT will be the easiest tool. Otherwise people want to see all times as expressed in their own time zone.

It would seem to me that you could reduce the resource size by translating only the zones for the explicit locale since the Olsen zones are explicit to a country.  This might be a better approach than translating all zones to the group I languages.   

The problem that I had with 3/4 letter times zones such as PST is the lack of standards.  Is "MST" "America/Denver", "America/Phoenix" or Moscow Summer Time?  Some people use "AST" for Alaska Standard Time instead of Atlantic Standard Time so there is room for confusion.  What about "America/Indianapolis" which technically changes from "EST" to "CDT".  (They move the time zone border twice a year).

I have found that from an application point of view 90+% of times should be in the time of the user.  For the rest can use GMT.  A nice standard might be one that shows the difference in local time so that you do not have to adjust the GMT offsets to local time but starting a new standard would probably be truly confusing.

On reports for the average user that need local time I often list the wall time as both local time and in the location of the user.  

The only real advantage I see in adding the tz name for parsing that is for the hour when you shift from DST and the times are ambiguous.

I am hesitant to implement a tool that does not work correctly at all time.  I try to avoid using the current ICU time zones in the date parsing and don't see how the changes will help.  Will this change affect the locale correct full date/time formats?

Carl