Time Zone Localizations
eggert at CS.UCLA.EDU
Sat Jun 12 07:37:05 UTC 2004
"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
* 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
* "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
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