Time Zone Localizations

[Mark Davis]

Thanks very much for your comments. I put up a new version of
http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/time_zone_localization.html
which tries to address these comments and some of the others that I've gotten on
this list.

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- 
From: "Paul Eggert" <eggert at CS.UCLA.EDU>
To: "Mark Davis" <mark.davis at jtcsv.com>
Cc: <tz at lecserver.nci.nih.gov>
Sent: Sat, 2004 Jun 12 00:37
Subject: Re: Time Zone Localizations


> "Mark Davis" <mark.davis at jtcsv.com> writes:
>
> >
http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/time_zone_localization.html
>
> Commenting on the version of 2004-06-11:
>
> * The document uses the term "CLDR" without defining it.
>
> *  'These translations mark a difference between "generic" usage (aka
>     "wall time") like "Pacific Time" and a fixed offset from GMT like
>     "Pacific Standard Time" or "Pacific Daylight Time", and also allow
>     for both abbreviated and full names.'
>
>   This doesn't seem to allow for variants in names (e.g. DST in Los
>   Angeles has variously been called "Pacific Daylight Time", "Pacific
>   War Time", and "Pacific Peace Time").  Nor does it seem to allow for
>   double DST.
>
> * The document defines "modern" equivalents as those that produce the
>   same result for the current year.  More accurate, I think, would be
>   that two zones would have to predict the same results for the
>   current year, the next year, the year after that, etc.  In some
>   cases two zones might predict the same results for the current year,
>   but not for next year.
>
> * "windows ids shows a mapping from windows IDs to Olson IDs."  You might
>   mention that this is a one-to-many mapping, and the Olson ID is chosen
>   somewhat arbitrarily.
>
> * "reset of the year" -> "rest of the year"
>
> * 'If there is an exact translation, use it.
>      America/Los_Angeles => "Pacific Time"'
>
>   This example doesn't seem to allow for the case where a city changes
>   time zones.  These things happen.  (It just happened in Argentina
>   last week.)
>
>   If you really want a name that means US Pacific Time, you'll need to
>   supply one.  Historically the Olson TZID "US/Pacific" served this
>   purpose, but it has been supplanted by geographical IDs partly to
>   avoid ambiguity, partly to avoid controversy.
>
> * 'America/Los_Angeles => "Tampo de San Fransisko"'
>   I don't understand this example.  Why is Los Angeles being translated
>   as if it were San Fransisco?
>
> * "Note that the results are semi-reversible; one cannot necessarily
>   recover the exact time zone that one started with, but can recover a
>   modern equivalent."  I don't understand this claim completely, but
>   I'm skeptical.  Natural-language time notations are notoriously
>   ambiguous.
>
> * "In Mexico one would prefer to see the America/Mexico_City timezone
>   (appropriately localized), while in the US, the America/Chicago
>   one."  This is not merely an issue of ease-of-use: it is also
>   important when one wants to specify the desired behavior in the
>   presence of likely future changes.  In 2001, the mayor of Mexico
>   City threatened to abolish DST in that city, and the matter remains
>   somewhat controversial, so it's quite possible that the Mexico City
>   and Chicago will diverge in the not-too-distant future.
>
> * Some of the document uses notations like "GMT+7" to mean west of
>   Greenwich; some of it uses the same notation to mean east of
>   Greenwich.  It should be consistent.  I suggest "GMT+7" to mean east
>   of Greenwich.  Also, these days it's more technically accurate to
>   write "UTC" instead of "GMT".
>
> * At the HTML level the document specifies charset=windows-1252 and
>   the four HTML lines containing non-ASCII characters didn't come out
>   right in my browser.  Can you please use plain ASCII instead, e.g.,
>   use "«" instead of the Windows-1252 byte that means
>   left-pointing double angle quotation mark?  Or it may be simpler to
>   reformulate the examples to avoid non-ASCII characters.
>
> * I don't really understand the proposal.  Sorry.  It's fairly
>   complicated and I don't fully understand the intended use or the
>   motivation.  Could be this is because I'm not in the CLDR universe.
>   Anyway, this means I can't really comment on the fundamentals of
>   the document, only on relatively-minor issues like the above.
>