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

A few comments on the 2004-06-12 edition:

* Re "Eastern European Daylight Time".  A more common English
  translation is "Eastern European Summer Time".  This is certainly
  true for British English, and tends to be true even for American
  sources like the Olson database.

  I think the usual idioms in practice are as follows.

   legend:
   -  generic time name (and abbreviation)
   0  standard time name (and abbreviation)
   1  daylight-saving time name (and abbreviation)

   example of typical American English style:
   -  Eastern Time (ET)  
   0  Eastern Standard Time (EST)
   1  Eastern Daylight Time (EDT)

   example of typical Australian English style:
   -  Eastern Time (ET)
   0  Eastern Standard Time (EST)
   1  Eastern Summer Time (EST)

   example of typical European English style:
   -  Eastern European Time (EET)
   0  Eastern European Time (EET)
   1  Eastern European Summer Time (EEST)

  Note that some names and/or abbreviations are ambiguous in some
  locales.  This suggests that one may run into some problems with the
  idea of having UIs use names to distinguish the cases labeled "-",
  "0", "1".

  This is somewhat related to the issue I previously mentioned that,
  even in the same locale, the name differs depending on what time
  stamps you're talking about.  For example "Pacific War Time" should
  be used for daylight-saving time in Los Angeles from 1942-02-09
  through 1945-08-14.

* I don't understand the syntax of the examples starting
  <ldml><dates>....

* Re "Note: the Olson TZIDs uses the opposite sign as RFC 822 with GMT
  formats".  This is because the Olson TZIDs use the same sign as
  POSIX TZ settings.

* "They are organized by cities" -> "They are organized by compact
  locations, typically cities."  Sometimes they're islands or bases.

As far as the requests go (in part F):

* "A list of the set of links to not skip".
  These would be all the Link lines that are mentioned in zone.tab.

* "The addition of unique TZIDs corresponding to the 'missing' ISO
  country codes BV, HM".  We've discussed this.  These areas are
  uninhabited and have no local time, so it's questionable that they
  need TZIDs.

  By the way, there's one other 'missing' ISO country code that I just
  discovered: AX, for the Aaland Islands.  (AX was added on February
  13 but nobody told us. :-) I'll add a new TZID Europe/Mariehamn for
  it, in my next proposed tz update.  It'll be an alias for
  Europe/Helsinki.

* "A mapping from some private-use ISO country code to the Etc/GMT*
  TZIDs."

  The Olson Etc/GMT* TZIDs are pretty much a subset of POSIX, which
  allows an essentially unlimited set of time zone IDs.  Most of the
  POSIX TZIDs will never be used in practice; conversely, the Olson
  Etc/GMT* TZIDs do not suffice (for example, they don't suffice for
  Los Angeles, or for India).

  I'm not sure it makes sense to single out the Etc/GMT* IDs.  Perhaps
  you need a way to specify any POSIX ID instead.