Re: Zone Localizations

thanks for your comments. my comments below.

Mark
__________________________________
http://www.macchiato.com
►  “Eppur si muove” ◄

----- Original Message ----- 
From: "Carl W. Brown" <[email protected]>
To: "icu-list" <[email protected]>
Sent: Tuesday, July 29, 2003 09:58
Subject: 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.

* Our goal is to give people the choices, and allow them to express
what they want. There are certainly circumstances where what one most
about is that it is at 17:30 New Dehli Time. If I tell you that
something happened at GMT+05:30, it doesn' convey the same information
unless you look up on your reference book to find out that that was
the timezone used in India.

Given that these are used in patterns, one could actually have both,
e.g.

hh:mm ZZZ '('ZZZZ')' =>

17:30 New Dehli Time (GMT+05:30)

>
> 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.

I don't know what you mean here.

>
> 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).

* The abbreviations, as is the case for *any* translation, have to
have the customary meaning for the language group in question. The
average speaker of American English would not understand MST to mean
Moscow!

This comes up as an issue mainly in countries that span time zones,
and themselves have subdesignations. There are edge cases that we have
to pick the best values for. The most accurate is a representation
that matches the Olson data more exactly, which is why we are
considering these changes.

There is some zone data that we will probably retract. For example
there are zone strings for Europe that are not in enough wide-spread
usage.

>
> 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.

I agree that most of the time the user probably wants the locale
timezone, if available. I disagree that the obvious alternative is
GMT; that is unfamiliar to many people.

>
> 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.

One can certainly do that with the tools we are considering making
available.

>
> 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.

We already have timezone parsing and formatting. What we are
considering are ways to make that more useful.

>
> 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.

If you think that the ICU parsing does not work in particular
instances, you should file a bug.

> Will this change affect the locale correct full date/time formats?

I think part of this change would be to change the full datetime
format to use 'zz' (default/indirect zone), and have that default map
to either walltime, city time or GMT offset, whichever is most common
for people in that area.

>
> Carl
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> icu mailing list
> [email protected]
> http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
>