Time Zone Localizations

[Mark Davis]

Thanks again. Some comments below.

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 19:31
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
>
> 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.

A bit of background. CLDR permits different translations for different locales,
so the same TZID could be translated as  "Eastern European Daylight Time" for
en_US (the US English locale), and "Eastern European Summer Time" for en_UK. It
all depends on what would be better understood in each place. Of course, if
there is a single term that would work for all English locales, it is better to
use that. I filed http://www.jtcsv.com/cgibin/locale-bugs?findid=152 on this.

>
>   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".

For any given locale, we would disallow a collision between names. Thus for the
locale en (English) we can't have AST mean both Alaska Standard Time and
Atlantic Standard Time. What we can do is have AST mean one in en_US and another
in en_CA (Canada).

>
>   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.

At this point, we are not really interested in translations of the way that
certain TZIDs would have been named in the past; it is enough of a problem to
get the present-day names!

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

The first line just lists the XML elements and attributes that are common to the
languages. The following lines list different translations. The locales using
each translation are listed surrounded by dots. The locale format is described
in http://www.unicode.org/reports/tr35/. Briefly, in all the cases mentioned it
is

language_code ("_" script_code)? ("_" territory_code)? // Perl notation

where the language code is the ISO 639 code. Thus en is English, fi is Finnish,
zh is Chinese, etc.

>
> * 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.

good notes, thanks

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

I hope you'll have patience with me on this, as I learn more about the
structure.

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

Good.
>
> * "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.

I agree that these are little rocks, of no value. So it is very odd that they
are given their own country codes by ISO. However, a lot of software is driven
by those ISO codes, so having them be missing may be a problem. Have to look
more into this.

>
>   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.

Thanks.
>
> * "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.

We certainly don't want all the POSIX IDs; as you say, they won't be used in
practice. The only reason for including the Etc/GMT* IDs would be if they are
needed. I had thought that to get all the timezones that are in use in the
world, including those in international waters, wouldn't we have to include the
Etc/GMT* ones? Or is this wrong?

>