December 2005 - tz - lists.iana.org

FW: FW: Re: Timezone name translations
by Olson, Arthur David (NIH/NCI) [E] Dec. 8, 2005

Dec. 8, 2005

-----Original Message----- From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Wednesday, December 07, 2005 1:05 PM To: Arthur David Olson Cc: tz(a)lecserver.nci.nih.gov Subject: Re: FW: Re: Timezone name translations Addressing the message: I would recommend using the TZIDs as is -- not try to invent new ones. You mention stability as being a concern: what we do in CLDR is to canonicalize the TZIDs for translation by choosing a particular one out of all the equivalent names (a choice we guarantee to be stable). Translating all of the TZIDs for all the languages is onerous, so for the zone identifiers in countries that only have a single zone, we leverage the country translations that we already have. We then can prioritize the translation of TZIDs that are in multizone countries. This information is then used in formatting the names, as per the following: http://www.unicode.org/draft/reports/tr35/tr35.html#Time_Zone_Fallback (This is the working draft of the next version, so modified text is in yellow). As an example of the data, see the translations in http://unicode.org/cldr/data/common/main/el.xml. Search for <territories> to see the translated country names. Search for <timeZoneNames> to see the translations for multizone countries (or particular other cases). Mark P.S. The abbreviations are ambiguous -- and not readily translated without introducing even further ambiguities -- so I would not recommend them for translation. Arthur David Olson wrote: >This message failed to make it out to the list. > > --ado > >From: Chuck Soper [chucks2(a)veladg.com] > >At 8:01 PM +0700 12/3/05, Stuart Bishop wrote: > > >>Paul Eggert wrote: >> >> > One problem with gettext format is that there might be multiple > >>translations for the same English-language abbreviation. For example, >> >> >>> "IST" is short for either Israel Standard Time or for India Standard >>>Time, and it's possible that the acronyms in (say) Russian would be >>>different. Hence gettext("IST") might not work as the user would >>>expect, in a Russian locale. >>> >>> >>This is a problem even without localization. But I won't be tackling >>abbreviations anyway - it would involve first mapping and translating >>each historical period in each timezone to an English sentence to cope >>with the duplicate abbreviations and the patalogical cases like >>Australian Eastern Standard Time and Australian Eastern Daylight >>Savings Time (still breaking code to this day). >> >> > >I'm interested in the display of time zone names both in English and localized. It seems like trying to provide a time zone name for each tzID (std/dst) might be fairly laborious because there are almost 400 tzIDs (in the zone.tab file). I'm considering building a time zone name table based time on abbreviations and UTC offsets. Each row in the table could have a tz abbreviation, a UTC offset and a time zone name. For example, one row could contain CET, UTC+1 and 'Central European Standard Time'. There are 34 tzIDs that use CET at UTC+1 during some time of the year. Instead of trying to maintain 34 tz names for 34 tzIDs why not maintain one tz name for an abbreviation and a UTC offset? Another example is Argentina. Doesn't Argentina have two tz names for its 10 tzIDs? For localized tz names, additional tables would be created. > >I understand that an abbreviation by itself is not unique (e.g. IST, EST, etc.), but the combination of an abbreviation and a UTC offset might be unique. Does anyone know if the abbreviation/UTC offset combination is unique? Clearly, tzIDs are unique, but they're not very stable and there are a lot of them. > >I believe that the abbreviation/UTC offset combination actually holds more information than a tzID. For example, PWT/UTC-7 (during World War II) could display Pacific War Time. The tzID by itself does not contain that information. Also, using only the tzID might produce some unneeded names if names are created tzID/dst combinations that do not exist. > >I'm interested to find out if people think this approach might be effective for building and maintaining a list of time zone names. > >Chuck > > > > > >

1 0

changes to zdump.c and zic.c invocations of is.* macros
by Arthur David Olson Dec. 6, 2005

Dec. 6, 2005

Below are proposed changes to zic.c and zdump.c to avoid compiler warnings about invocations of the is.* macros, to meet standard requirements for calling the macros, and to make the invocations consistent. I plan to deal with gettext issues in the next round of changes. --ado ------- zic.c ------- *** /tmp/geta6691 Tue Dec 6 11:01:47 2005 --- /tmp/getb6691 Tue Dec 6 11:01:47 2005 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zic.c 7.124"; /* ** Regardless of the type of time_t, we do our work using this type. --- 1,4 ---- ! static char elsieid[] = "@(#)zic.c 7.125"; /* ** Regardless of the type of time_t, we do our work using this type. *************** *** 2046,2053 **** emalloc((int) ((strlen(cp) + 1) * sizeof *array)); nsubs = 0; for ( ; ; ) { ! while (isascii(*cp) && isspace((unsigned char) *cp)) ! ++cp; if (*cp == '\0' || *cp == '#') break; array[nsubs++] = dp = cp; --- 2046,2054 ---- emalloc((int) ((strlen(cp) + 1) * sizeof *array)); nsubs = 0; for ( ; ; ) { ! while (isascii((unsigned char) *cp) && ! isspace((unsigned char) *cp)) ! ++cp; if (*cp == '\0' || *cp == '#') break; array[nsubs++] = dp = cp; *************** *** 2210,2217 **** */ cp = string; wp = NULL; ! while (isascii(*cp) && isalpha(*cp)) ! ++cp; if (cp - string == 0) wp = _("time zone abbreviation lacks alphabetic at start"); if (noise && cp - string > 3) --- 2211,2219 ---- */ cp = string; wp = NULL; ! while (isascii((unsigned char) *cp) && ! isalpha((unsigned char) *cp)) ! ++cp; if (cp - string == 0) wp = _("time zone abbreviation lacks alphabetic at start"); if (noise && cp - string > 3) *************** *** 2220,2228 **** wp = _("time zone abbreviation has too many alphabetics"); if (wp == NULL && (*cp == '+' || *cp == '-')) { ++cp; ! if (isascii(*cp) && isdigit(*cp)) ! if (*cp++ == '1' && *cp >= '0' && *cp <= '4') ! ++cp; } if (*cp != '\0') wp = _("time zone abbreviation differs from POSIX standard"); --- 2222,2232 ---- wp = _("time zone abbreviation has too many alphabetics"); if (wp == NULL && (*cp == '+' || *cp == '-')) { ++cp; ! if (isascii((unsigned char) *cp) && ! isdigit((unsigned char) *cp)) ! if (*cp++ == '1' && ! *cp >= '0' && *cp <= '4') ! ++cp; } if (*cp != '\0') wp = _("time zone abbreviation differs from POSIX standard"); ------- zdump.c ------- *** /tmp/geta6709 Tue Dec 6 11:01:48 2005 --- /tmp/getb6709 Tue Dec 6 11:01:48 2005 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zdump.c 7.70"; /* ** This code has been made independent of the rest of the time --- 1,4 ---- ! static char elsieid[] = "@(#)zdump.c 7.71"; /* ** This code has been made independent of the rest of the time *************** *** 209,215 **** return; cp = abbrp; wp = NULL; ! while (isascii(*cp) && isalpha(*cp)) ++cp; if (cp - abbrp == 0) wp = _("lacks alphabetic at start"); --- 209,215 ---- return; cp = abbrp; wp = NULL; ! while (isascii((unsigned char) *cp) && isalpha((unsigned char) *cp)) ++cp; if (cp - abbrp == 0) wp = _("lacks alphabetic at start"); *************** *** 219,227 **** wp = _("has more than 6 alphabetics"); if (wp == NULL && (*cp == '+' || *cp == '-')) { ++cp; ! if (isascii(*cp) && isdigit(*cp)) ! if (*cp++ == '1' && *cp >= '0' && *cp <= '4') ! ++cp; } if (*cp != '\0') wp = _("differs from POSIX standard"); --- 219,228 ---- wp = _("has more than 6 alphabetics"); if (wp == NULL && (*cp == '+' || *cp == '-')) { ++cp; ! if (isascii((unsigned char) *cp) && ! isdigit((unsigned char) *cp)) ! if (*cp++ == '1' && *cp >= '0' && *cp <= '4') ! ++cp; } if (*cp != '\0') wp = _("differs from POSIX standard");

2 1

FW: Re: Timezone name translations
by Arthur David Olson Dec. 6, 2005

Dec. 6, 2005

This message failed to make it out to the list. --ado From: Chuck Soper [chucks2(a)veladg.com] At 8:01 PM +0700 12/3/05, Stuart Bishop wrote: >Paul Eggert wrote: > > > One problem with gettext format is that there might be multiple > > translations for the same English-language abbreviation. For example, >> "IST" is short for either Israel Standard Time or for India Standard >> Time, and it's possible that the acronyms in (say) Russian would be >> different. Hence gettext("IST") might not work as the user would >> expect, in a Russian locale. > >This is a problem even without localization. But I won't be tackling >abbreviations anyway - it would involve first mapping and translating >each historical period in each timezone to an English sentence to cope >with the duplicate abbreviations and the patalogical cases like >Australian Eastern Standard Time and Australian Eastern Daylight >Savings Time (still breaking code to this day). I'm interested in the display of time zone names both in English and localized. It seems like trying to provide a time zone name for each tzID (std/dst) might be fairly laborious because there are almost 400 tzIDs (in the zone.tab file). I'm considering building a time zone name table based time on abbreviations and UTC offsets. Each row in the table could have a tz abbreviation, a UTC offset and a time zone name. For example, one row could contain CET, UTC+1 and 'Central European Standard Time'. There are 34 tzIDs that use CET at UTC+1 during some time of the year. Instead of trying to maintain 34 tz names for 34 tzIDs why not maintain one tz name for an abbreviation and a UTC offset? Another example is Argentina. Doesn't Argentina have two tz names for its 10 tzIDs? For localized tz names, additional tables would be created. I understand that an abbreviation by itself is not unique (e.g. IST, EST, etc.), but the combination of an abbreviation and a UTC offset might be unique. Does anyone know if the abbreviation/UTC offset combination is unique? Clearly, tzIDs are unique, but they're not very stable and there are a lot of them. I believe that the abbreviation/UTC offset combination actually holds more information than a tzID. For example, PWT/UTC-7 (during World War II) could display Pacific War Time. The tzID by itself does not contain that information. Also, using only the tzID might produce some unneeded names if names are created tzID/dst combinations that do not exist. I'm interested to find out if people think this approach might be effective for building and maintaining a list of time zone names. Chuck

1 0

Re: Timezone name translations
by Paul Eggert Dec. 6, 2005

Dec. 6, 2005

Chuck Soper <chucks2(a)veladg.com> writes: > Does anyone know if the abbreviation/UTC offset combination is > unique? I wouldn't count on it. Does "PST" mean "Pacific Standard Time" or "Pitcairn Standard Time"? They're both 8 hours behind UTC. Or, if you want something a bit more obscure, "LMT" at 36 minutes and 32 seconds behind UTC can mean either "Local Mean Time" or "Lisbon Mean Time", depending on the zone and year. Neither of these examples are of major economic importance right now, but they do indicate the assumption isn't safe.

1 0

RE: Tzcode2005p.tar.gz and tzdata2005p.tar.gz
by Olson, Arthur David (NIH/NCI) [E] Dec. 5, 2005

Dec. 5, 2005

Thanks; I'll incorporate that in the next round. --ado -----Original Message----- From: Paul Eggert [mailto:eggert@CS.UCLA.EDU] Sent: Monday, December 05, 2005 4:34 PM To: Olson, Arthur David (NIH/NCI) [E] Cc: tz(a)elsie.nci.nih.gov Subject: Re: Tzcode2005p.tar.gz and tzdata2005p.tar.gz I suggest the following one-line comment change to the systemv file, the next time it gets published. It addresses two issues. First, the "before" in the old comment is backwards, as the US DST changes occurred after (not before) the old System V rules were written. Second, we now have two sets of US changes (1987 and 2007), not one, so the comment shouldn't imply that the 1987 changes were the only ones. --- systemv 2005/11/29 19:04:59 2005.16 +++ systemv 2005/12/05 21:29:02 2005.16.0.1 @@ -4,7 +4,7 @@ # No attempt is made to handle Newfoundland, since it cannot be expressed # using the System V "TZ" scheme (half-hour offset), or anything outside # North America (no support for non-standard DST start/end dates), nor -# the change in the DST rules in the US in 1987 (which occurred before +# the changes in the DST rules in the US after 1976 (which occurred after # the old rules were written). # # If you need the old rules, uncomment ## lines.

1 0

Tzcode2005p.tar.gz and tzdata2005p.tar.gz
by Olson, Arthur David (NIH/NCI) [E] Dec. 5, 2005

Dec. 5, 2005

The files... ftp://elsie.nci.nih.gov/pub/tzcode2005p.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2005p.tar.gz ...are now available. These reflect the "systemv", "tz-link.htm", and "zdump.c" changes circulated last week on the time zone mailing list (less the casts of arguments to the is* macros). My hope is to do a bit more cleanup by the end of the year: 1. Reflect on and then incorporate the zdump.c changes from Robin Kawabata. 2. Finish off the work on zones such as EST5EDT. 3. Finish the work of purging electronic mail address. 4. Fix (or at least annotate) dead URLs in the data files. Once 2006 rolls around I'll have another go at getting consensus on 64-bit changes. --ado

2 1

URL glitches in data files
by Arthur David Olson Dec. 5, 2005

Dec. 5, 2005

Below find information on five glitchy URLs (one of which appears twice) in the time zone data files. I struck out in my browser spelunking effort to find replacements. If anyone knows of working versions, let me know; absent that, I'll add appropriate notes to the data file. --adO <html> <body> <pre> antarctica: http://www.icair.iac.org.nz/science/reports/fr/IFRTP.html; NSLOOKUP FAILS # Reference: # <a href="http://www.icair.iac.org.nz/science/reports/fr/IFRTP.html"> # Support and Development of Polar Research and Technology (1997-02-03) # </a> australasia: http://www.nsc.gov.au/InfoServ/Ileaflet/il27.htm; NSLOOKUP FAILS # From Paul Eggert (1999-09-27): # The Information Service of the Australian National Standards Commission # <a href="http://www.nsc.gov.au/InfoServ/Ileaflet/il27.htm"> # Daylight Saving # </a> page (1995-04) has an excellent overall history of Australian DST. antarctica: http://www.crl.go.jp/uk/uk201/basyo.htm; NSLOOKUP FAILS (www.crl.co.jp exists; changing co to go above still fails.) # From Hideyuki Suzuki (1999-02-06): # In all Japanese stations, +0300 is used as the standard time. [See] # <a href="http://www.crl.go.jp/uk/uk201/basyo.htm">[reference in Japanese]</a> # and information from KAMO Hiroyasu. antarctica: http://www.dstc.qut.edu.au/DST/marg/daylight.html; NSLOOKUP FAILS # Australia - territories # Heard Island, McDonald Islands (uninhabited) # previously sealers and scientific personnel wintered # <a href="http://www.dstc.qut.edu.au/DST/marg/daylight.html"> # Margaret Turner reports # </a> (1999-09-30) that they're UTC+5, with no DST; # presumably this is when they have visitors. australasia: http://www.dstc.qut.edu.au/DST/marg/daylight.html; NSLOOKUP FAILS # <a href="http://www.dstc.qut.edu.au/DST/marg/daylight.html"> # Australia's Daylight Saving Times # </a>, by Margaret Turner, summarizes daylight saving issues in Australia. southamerica: http://churchnet.ucsm.ac.uk/news/files2/news165.htm; NSLOOKUP WORKS; TIMES OUT # From Paul Eggert (1998-02-25): # <a href="http://churchnet.ucsm.ac.uk/news/files2/news165.htm"> # Brazil Prepares for Papal Visit # </a>, # Church Net UK (1997-10-02).

1 0

Timezone name translations
by Stuart Bishop Dec. 2, 2005

Dec. 2, 2005

Can anyone point me to a public domain or liberally licenced database of translations of timezone names? Preferably in gettext po file format. I can generate the po template, and I'd prefer to track down translations now rather than waste translators' time later. -- Stuart Bishop <stuart(a)stuartbishop.net> http://www.stuartbishop.net/

2 1