Time Zone Localizations
mark.davis at jtcsv.com
Sat Jun 12 20:15:23 UTC 2004
Thanks very much for your comments. I put up a new version of
which tries to address these comments and some of the others that I've gotten on
► शिष्यादिच्छेत्पराजयम् ◄
----- 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:
> 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
> * "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.
More information about the tz