Time Zone Localizations

[Paul Eggert]

"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 "&laquo;" 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.