- 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

one more (non-controversial) change (to tz-link.htm)
by Arthur David Olson Nov. 29, 2005

Nov. 29, 2005

This change just make for consistent href quoting in tz-link.htm; it was the only place where single quotes were used rather than double quotes. --ado ------- tz-link.htm ------- *** /tmp/geta1738 Tue Nov 29 14:31:10 2005 --- /tmp/getb1738 Tue Nov 29 14:31:10 2005 *************** *** 19,25 **** <body> <h1>Sources for Time Zone and Daylight Saving Time Data</h1> <address> ! @(#)tz-link.htm 7.52 </address> <p> Please send corrections to this web page to the --- 19,25 ---- <body> <h1>Sources for Time Zone and Daylight Saving Time Data</h1> <address> ! @(#)tz-link.htm 7.53 </address> <p> Please send corrections to this web page to the *************** *** 140,146 **** title="Calendaring and Scheduling Working Group">calsch</abbr>)</a> covers time zone data; see its VTIMEZONE calendar component. ! The <a href='http://www.calconnect.org/'>Calendaring and Scheduling Consortium</a> is promoting further work in this area.</li> <li>The <a href="http://lists.w3.org/Archives/Public/www-rdf-calendar/">www-rdf-calendar</a> --- 140,146 ---- title="Calendaring and Scheduling Working Group">calsch</abbr>)</a> covers time zone data; see its VTIMEZONE calendar component. ! The <a href="http://www.calconnect.org/">Calendaring and Scheduling Consortium</a> is promoting further work in this area.</li> <li>The <a href="http://lists.w3.org/Archives/Public/www-rdf-calendar/">www-rdf-calendar</a>

1 0

proposed changes to zdump.c and systemv
by Arthur David Olson Nov. 29, 2005

Nov. 29, 2005

Below find proposed changes to zdump.c to eliminate some lint and to remove an electronic mail address (in our current age of address hunting-and-abusing software; more address elimination is to follow). Also find changes to systemv; the file is left in place, but without any active "Zone" lines so now binary data is generated. I've uncommented the "Rule" lines to provide a continuing check of their validity (in case the input accepted by "zic" changes) and to minimize the changes needed should someone actually want to generate System V time zone files. --ado ------- zdump.c ------- *** /tmp/geta62 Tue Nov 29 11:21:35 2005 --- /tmp/getb62 Tue Nov 29 11:21:35 2005 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zdump.c 7.68"; /* ** This code has been made independent of the rest of the time --- 1,4 ---- ! static char elsieid[] = "@(#)zdump.c 7.69"; /* ** This code has been made independent of the rest of the time *************** *** 12,17 **** --- 12,21 ---- #include "time.h" /* for struct tm */ #include "stdlib.h" /* for exit, malloc, atoi */ #include "float.h" /* for FLT_MAX and DBL_MAX */ + #include "ctype.h" /* for isalpha et al. */ + #ifndef isascii + #define isascii(x) 1 + #endif #ifndef ZDUMP_LO_YEAR #define ZDUMP_LO_YEAR (-500) *************** *** 205,211 **** 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((int) *cp) && isalpha((int) *cp)) ++cp; if (cp - abbrp == 0) wp = _("lacks alphabetic at start"); *************** *** 215,221 **** 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; } --- 219,225 ---- wp = _("has more than 6 alphabetics"); if (wp == NULL && (*cp == '+' || *cp == '-')) { ++cp; ! if (isascii((int) *cp) && isdigit((int) *cp)) if (*cp++ == '1' && *cp >= '0' && *cp <= '4') ++cp; } *************** *** 509,515 **** } /* ! ** Thanks to Paul Eggert (eggert(a)twinsun.com) for logic used in delta. */ static long --- 513,519 ---- } /* ! ** Thanks to Paul Eggert for logic used in delta. */ static long ------- systemv ------- *** /tmp/geta119 Tue Nov 29 11:22:22 2005 --- /tmp/getb119 Tue Nov 29 11:22:22 2005 *************** *** 1,4 **** ! # @(#)systemv 7.3 # Old rules, should the need arise. # No attempt is made to handle Newfoundland, since it cannot be expressed --- 1,4 ---- ! # @(#)systemv 7.4 # Old rules, should the need arise. # No attempt is made to handle Newfoundland, since it cannot be expressed *************** *** 7,24 **** # the change in the DST rules in the US in 1987 (which occurred before # the old rules were written). # ! # If you need the old rules, uncomment ## lines and comment-out Link lines. # Compile this *without* leap second correction for true conformance. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! ## Rule SystemV min 1973 - Apr lastSun 2:00 1:00 D ! ## Rule SystemV min 1973 - Oct lastSun 2:00 0 S ! ## Rule SystemV 1974 only - Jan 6 2:00 1:00 D ! ## Rule SystemV 1974 only - Nov lastSun 2:00 0 S ! ## Rule SystemV 1975 only - Feb 23 2:00 1:00 D ! ## Rule SystemV 1975 only - Oct lastSun 2:00 0 S ! ## Rule SystemV 1976 max - Apr lastSun 2:00 1:00 D ! ## Rule SystemV 1976 max - Oct lastSun 2:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] ## Zone SystemV/AST4ADT -4:00 SystemV A%sT --- 7,24 ---- # the change in the DST rules in the US in 1987 (which occurred before # the old rules were written). # ! # If you need the old rules, uncomment ## lines. # Compile this *without* leap second correction for true conformance. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! Rule SystemV min 1973 - Apr lastSun 2:00 1:00 D ! Rule SystemV min 1973 - Oct lastSun 2:00 0 S ! Rule SystemV 1974 only - Jan 6 2:00 1:00 D ! Rule SystemV 1974 only - Nov lastSun 2:00 0 S ! Rule SystemV 1975 only - Feb 23 2:00 1:00 D ! Rule SystemV 1975 only - Oct lastSun 2:00 0 S ! Rule SystemV 1976 max - Apr lastSun 2:00 1:00 D ! Rule SystemV 1976 max - Oct lastSun 2:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] ## Zone SystemV/AST4ADT -4:00 SystemV A%sT *************** *** 34,50 **** ## Zone SystemV/PST8 -8:00 - PST ## Zone SystemV/YST9 -9:00 - YST ## Zone SystemV/HST10 -10:00 - HST - # For now... - Link America/Halifax SystemV/AST4ADT - Link America/New_York SystemV/EST5EDT - Link America/Chicago SystemV/CST6CDT - Link America/Denver SystemV/MST7MDT - Link America/Los_Angeles SystemV/PST8PDT - Link America/Anchorage SystemV/YST9YDT - Link America/Puerto_Rico SystemV/AST4 - Link America/Indianapolis SystemV/EST5 - Link America/Regina SystemV/CST6 - Link America/Phoenix SystemV/MST7 - Link Pacific/Pitcairn SystemV/PST8 - Link Pacific/Gambier SystemV/YST9 - Link Pacific/Honolulu SystemV/HST10 --- 34,36 ----

1 0

New US DST rules versus federal elections (with prediction)
by Olson, Arthur David (NIH/NCI) Nov. 28, 2005

Nov. 28, 2005

An oddity of the new US DST rules: in most federal election years the switch back to standard time comes before the federal election, but in years when the seventh of November falls on a Sunday, the switch back comes after the federal election (see below). Operating under the assumptions that (all other things being equal) voter turnout is greater when DST is in effect, and given that in recent years Democrats have been more eager than Republicans for increased voter turnout, I predict a change in the rules once the implication sinks in (possibly before the 2010 elections). --ado America/New_York Sun Nov 2 06:00:00 2008 UTC = Sun Nov 2 01:00:00 2008 EST isdst=0 before presidential America/New_York Sun Nov 7 06:00:00 2010 UTC = Sun Nov 7 01:00:00 2010 EST isdst=0 after off-year America/New_York Sun Nov 4 06:00:00 2012 UTC = Sun Nov 4 01:00:00 2012 EST isdst=0 before presidential America/New_York Sun Nov 2 06:00:00 2014 UTC = Sun Nov 2 01:00:00 2014 EST isdst=0 before off-year America/New_York Sun Nov 6 06:00:00 2016 UTC = Sun Nov 6 01:00:00 2016 EST isdst=0 before presidential America/New_York Sun Nov 4 06:00:00 2018 UTC = Sun Nov 4 01:00:00 2018 EST isdst=0 before off-year America/New_York Sun Nov 1 06:00:00 2020 UTC = Sun Nov 1 01:00:00 2020 EST isdst=0 before presidential America/New_York Sun Nov 6 06:00:00 2022 UTC = Sun Nov 6 01:00:00 2022 EST isdst=0 before off-year America/New_York Sun Nov 3 06:00:00 2024 UTC = Sun Nov 3 01:00:00 2024 EST isdst=0 before presidential America/New_York Sun Nov 1 06:00:00 2026 UTC = Sun Nov 1 01:00:00 2026 EST isdst=0 before off-year America/New_York Sun Nov 5 06:00:00 2028 UTC = Sun Nov 5 01:00:00 2028 EST isdst=0 before presidential America/New_York Sun Nov 3 06:00:00 2030 UTC = Sun Nov 3 01:00:00 2030 EST isdst=0 before off-year America/New_York Sun Nov 7 06:00:00 2032 UTC = Sun Nov 7 01:00:00 2032 EST isdst=0 after presidential America/New_York Sun Nov 5 06:00:00 2034 UTC = Sun Nov 5 01:00:00 2034 EST isdst=0 before off-year America/New_York Sun Nov 2 06:00:00 2036 UTC = Sun Nov 2 01:00:00 2036 EST isdst=0 before presidential

1 0

Tzcode2005o.tar.gz and tzdata2005o.tar.gz
by Olson, Arthur David (NIH/NCI) Nov. 28, 2005

Nov. 28, 2005

The files... ftp://elsie.nci.nih.gov/pub/tzcode2005o.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2005o.tar.gz ...are now available. These incorporate the Georgia, Cuba, Nicaragua, and Jordan changes circulated over the past two weeks by Paul Eggert on the time zone mailing list. They also incorporate the zdump.c lint fixes circulated by yours truly. No changes to backward and systemv at this time; stay tuned. --ado

1 0

Re: TZ changes in Nicaragua, Jordan and Gaza
by Paul Eggert Nov. 23, 2005

Nov. 23, 2005

Thanks for the heads-up. As you mention, reliable data for Gaza in English is hard to come by, but what little info I can find corroborates timeanddate.com. Here's a further proposed patch to the tz database embodying those changes. It assumes the System V patches I proposed yesterday and also the Georgia / Cuba/ Azerbaijan changes of a week ago. =================================================================== RCS file: RCS/asia,v retrieving revision 2005.14.0.1 retrieving revision 2005.14.0.2 diff -pu -r2005.14.0.1 -r2005.14.0.2 --- asia 2005/11/18 06:54:05 2005.14.0.1 +++ asia 2005/11/23 08:18:53 2005.14.0.2 @@ -930,6 +930,9 @@ Zone Asia/Tokyo 9:18:59 - LMT 1887 Dec 3 # The decision was taken because of the increase in working hours in # government's departments from six to seven hours. # +# From Paul Eggert (2005-11-22): +# Starting 2003 transitions are from Steffen Thorsen's web site timeanddate.com. +# # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Jordan 1973 only - Jun 6 0:00 1:00 S Rule Jordan 1973 1975 - Oct 1 0:00 0 - @@ -952,8 +955,11 @@ Rule Jordan 1993 1998 - Apr Fri>=1 0:00 Rule Jordan 1994 only - Sep Fri>=15 0:00 0 - Rule Jordan 1995 1998 - Sep Fri>=15 0:00s 0 - Rule Jordan 1999 only - Jul 1 0:00s 1:00 S -Rule Jordan 1999 max - Sep lastThu 0:00s 0 - +Rule Jordan 1999 2002 - Sep lastThu 0:00s 0 - Rule Jordan 2000 max - Mar lastThu 0:00s 1:00 S +Rule Jordan 2003 only - Oct 24 0:00s 0 - +Rule Jordan 2004 only - Oct 15 0:00s 0 - +Rule Jordan 2005 max - Sep lastFri 0:00s 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Amman 2:23:44 - LMT 1931 2:00 Jordan EE%sT @@ -1423,6 +1429,9 @@ Zone Asia/Karachi 4:28:12 - LMT 1907 # For now, let's assume that the spring switch was at 24:00, # and that they switch at 0:00 on the 3rd Fridays of April and October. +# From Paul Eggert (2005-11-22): +# Starting 2004 transitions are from Steffen Thorsen's web site timeanddate.com. + # The rules for Egypt are stolen from the `africa' file. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule EgyptAsia 1957 only - May 10 0:00 1:00 S @@ -1433,7 +1442,9 @@ Rule EgyptAsia 1959 1965 - Sep 30 3:00 0 Rule EgyptAsia 1966 only - Oct 1 3:00 0 - Rule Palestine 1999 max - Apr Fri>=15 0:00 1:00 S -Rule Palestine 1999 max - Oct Fri>=15 0:00 0 - +Rule Palestine 1999 2003 - Oct Fri>=15 0:00 0 - +Rule Palestine 2004 only - Oct 1 1:00 0 - +Rule Palestine 2005 max - Oct 4 1:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Gaza 2:17:52 - LMT 1900 Oct =================================================================== RCS file: RCS/northamerica,v retrieving revision 2005.14.0.2 retrieving revision 2005.14.0.3 diff -pu -r2005.14.0.2 -r2005.14.0.3 --- northamerica 2005/11/22 18:04:38 2005.14.0.2 +++ northamerica 2005/11/23 08:18:53 2005.14.0.3 @@ -2037,13 +2037,18 @@ Zone America/Montserrat -4:08:52 - LMT 1 # changes in 2000. Perhaps a note could be added to the northamerica file, to # the effect that we have indirect evidence that DST was observed in 2000. # +# From Jesper Norgaard Welen (2005-11-02): +# Nicaragua left DST the 2005-10-02 at 00:00 (local time). +# http://www.presidencia.gob.ni/presidencia/files_index/secretaria/comunicado… +# (2005-09-26) +# # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Nic 1979 1980 - Mar Sun>=16 0:00 1:00 D Rule Nic 1979 1980 - Jun Mon>=23 0:00 0 S -Rule Nic 1992 only - Jan 1 4:00 1:00 D +Rule Nic 1992 only - Jan 1 4:00 1:00 D Rule Nic 1992 only - Sep 24 0:00 0 S Rule Nic 2005 only - Apr 10 0:00 1:00 D -Rule Nic 2005 only - Sep 18 0:00 0 S +Rule Nic 2005 only - Oct 2 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Managua -5:45:08 - LMT 1890 -5:45:12 - MMT 1934 Jun 23 # Managua Mean Time?

2 1

RE: proposed tz changes (zdump.c, backward, and systemv)
by Olson, Arthur David (NIH/NCI) Nov. 22, 2005

Nov. 22, 2005

I'll hold off on changing backward and systemv in the upcoming Monday distribution; it's important to get other changes out at that point since some of them effect current clocks. The best approach to take on the systemv stuff may be to simply eliminate it from the distribution. The systemv stuff was included way back in 1986 when System V was still relevant; twenty years later it can presumably be dispensed with. On the backward side: a characteristic of the time zone compiler is that it doesn't clear out the destination directory before putting results there, so existing files remain unless they're replaced. Further, if a binary file exists with a name that matches that of the TZ environment variable, the data in the binary file is used even if the TZ value is something such as "EST5EDT". So we do want to generate binary files for EST5EDT et al. to ensure that no bad data remains in the destination directory. To avoid having US rules in both "northamerica" and "backward" (introducing the possibility that the rules get out of sync), we could put the "Zone EST5EDT ..." stuff in the northamerica file (where the US rules currently appear). If we do end up with two copies of the US rules, we'll want to make sure that there's a comment with each copy indicating the need to keep it in sync with the other copy. --ado

2 1

FW: proposed tz changes (zdump.c, backward, and systemv)
by Olson, Arthur David (NIH/NCI) Nov. 21, 2005

Nov. 21, 2005

The attached may not have made it to the time zone mailing list; just in case... --ado -----Original Message----- From: Paul Eggert [mailto:eggert@CS.UCLA.EDU] Sent: Monday, November 21, 2005 3:38 PM To: Arthur David Olson Cc: tz(a)lecserver.nci.nih.gov Subject: Re: proposed tz changes (zdump.c, backward, and systemv) Arthur David Olson <olsona(a)elsie.nci.nih.gov> writes: > + Zone AST4ADT -4:00 US A%sT This change, in the 'backward' file, would mean that 'backward' could not be compiled independently from 'northamerica'. Also, the tz database currently does not have an entry for TZ='AST4ADT'. Surely it's not necessary to add a new name that uses that long-obsolete naming convention? + Zone AST4 -4:00 - AST Lines like this one aren't necessary, since TZ='AST4' already works. Or perhaps you meant "Zone AST"? In that case, the same argument applies as for AST4ADT; there's no current entry, and we don't need to add new entries that use a long-obsolete naming scheme. How about this change instead? It's more conservative, in that it doesn't create any new names; also, it addresses the other issues mentioned above. =================================================================== RCS file: RCS/backward,v retrieving revision 2005.13 retrieving revision 2005.13.0.2 diff -pu -r2005.13 -r2005.13.0.2 --- backward 2005/08/29 15:54:31 2005.13 +++ backward 2005/11/21 20:35:28 2005.13.0.2 @@ -42,7 +42,7 @@ Link America/Rio_Branco Brazil/Acre Link America/Noronha Brazil/DeNoronha Link America/Sao_Paulo Brazil/East Link America/Manaus Brazil/West -Link America/Chicago CST6CDT +Link SystemV/CST6CDT CST6CDT Link America/Halifax Canada/Atlantic Link America/Winnipeg Canada/Central Link America/Regina Canada/East-Saskatchewan @@ -55,8 +55,8 @@ Link America/Whitehorse Canada/Yukon Link America/Santiago Chile/Continental Link Pacific/Easter Chile/EasterIsland Link America/Havana Cuba -Link America/Panama EST -Link America/New_York EST5EDT +Link SystemV/EST5 EST +Link SystemV/EST5EDT EST5EDT Link Africa/Cairo Egypt Link Europe/Dublin Eire Link Europe/London Europe/Belfast @@ -67,7 +67,7 @@ Link Etc/GMT GMT+0 Link Etc/GMT GMT-0 Link Etc/GMT GMT0 Link Etc/GMT Greenwich -Link Pacific/Honolulu HST +Link SystemV/HST10 HST Link Asia/Hong_Kong Hongkong Link Atlantic/Reykjavik Iceland Link Asia/Tehran Iran @@ -76,8 +76,8 @@ Link America/Jamaica Jamaica Link Asia/Tokyo Japan Link Pacific/Kwajalein Kwajalein Link Africa/Tripoli Libya -Link America/Phoenix MST -Link America/Denver MST7MDT +Link SystemV/MST7 MST +Link SystemV/MST7MDT MST7MDT Link America/Tijuana Mexico/BajaNorte Link America/Mazatlan Mexico/BajaSur Link America/Mexico_City Mexico/General @@ -85,7 +85,7 @@ Link Pacific/Auckland NZ Link Pacific/Chatham NZ-CHAT Link America/Denver Navajo Link Asia/Shanghai PRC -Link America/Los_Angeles PST8PDT +Link SystemV/PST8PDT PST8PDT Link Pacific/Pago_Pago Pacific/Samoa Link Pacific/Truk Pacific/Yap Link Europe/Warsaw Poland =================================================================== RCS file: RCS/systemv,v retrieving revision 2001.1.0.2 retrieving revision 2001.1.0.2.0.2 diff -pu -r2001.1.0.2 -r2001.1.0.2.0.2 --- systemv 2005/10/04 04:31:57 2001.1.0.2 +++ systemv 2005/11/21 20:35:28 2001.1.0.2.0.2 @@ -7,7 +7,8 @@ # 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 and comment-out Link lines. +# If you need the old rules, uncomment ## lines and # comment-out lines +at the end of the file. # Compile this *without* leap second correction for true conformance. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S @@ -34,17 +35,36 @@ ## Zone SystemV/PST8 -8:00 - PST ## Zone SystemV/YST9 -9:00 - YST ## Zone SystemV/HST10 -10:00 - HST -# For now... -Link America/Halifax SystemV/AST4ADT -Link America/New_York SystemV/EST5EDT -Link America/Chicago SystemV/CST6CDT -Link America/Denver SystemV/MST7MDT -Link America/Los_Angeles SystemV/PST8PDT -Link America/Anchorage SystemV/YST9YDT -Link America/Puerto_Rico SystemV/AST4 -Link America/Panama SystemV/EST5 -Link America/Regina SystemV/CST6 -Link America/Phoenix SystemV/MST7 -Link Pacific/Pitcairn SystemV/PST8 -Link Pacific/Gambier SystemV/YST9 -Link Pacific/Honolulu SystemV/HST10 + +# A copy of the US rules from 'northamerica'. +# The copy is so that 'systemv' can be compiled independently. +# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S +Rule US-sysv 1918 1919 - Mar lastSun 2:00 1:00 D +Rule US-sysv 1918 1919 - Oct lastSun 2:00 0 S +Rule US-sysv 1942 only - Feb 9 2:00 1:00 W # War +Rule US-sysv 1945 only - Aug 14 23:00u 1:00 P # Peace +Rule US-sysv 1945 only - Sep 30 2:00 0 S +Rule US-sysv 1967 2006 - Oct lastSun 2:00 0 S +Rule US-sysv 1967 1973 - Apr lastSun 2:00 1:00 D +Rule US-sysv 1974 only - Jan 6 2:00 1:00 D +Rule US-sysv 1975 only - Feb 23 2:00 1:00 D +Rule US-sysv 1976 1986 - Apr lastSun 2:00 1:00 D +Rule US-sysv 1987 2006 - Apr Sun>=1 2:00 1:00 D +Rule US-sysv 2007 max - Mar Sun>=8 2:00 1:00 D +Rule US-sysv 2007 max - Nov Sun>=1 2:00 0 S + +# Zone NAME GMTOFF RULES FORMAT +Zone SystemV/AST4 -4:00 - AST +Zone SystemV/EST5 -5:00 - EST +Zone SystemV/CST6 -6:00 - CST +Zone SystemV/MST7 -7:00 - MST +Zone SystemV/PST8 -8:00 - PST +Zone SystemV/YST9 -9:00 - YST +Zone SystemV/HST10 -10:00 - HST + +Zone SystemV/AST4ADT -4:00 US-sysv A%sT +Zone SystemV/EST5EDT -5:00 US-sysv E%sT +Zone SystemV/CST6CDT -6:00 US-sysv C%sT +Zone SystemV/MST7MDT -7:00 US-sysv M%sT +Zone SystemV/PST8PDT -8:00 US-sysv P%sT +Zone SystemV/YST9YDT -9:00 US-sysv Y%sT

1 0

proposed tz changes (zdump.c, backward, and systemv)
by Arthur David Olson Nov. 21, 2005

Nov. 21, 2005

Here are proposed changes to three files: to zdump.c (allowing internationalization of one message and cleaning up some name-shadowing lint); and backward and systemv (creating distinct binary files for old-style names rather than linking them to particular geographic areas that might change rules). I'll let both these proposals and Paul Eggert's proposals (circulated on the list this last Friday) to cook over Thanksgiving; barring objections, I'll propogate them to the ftp server next Monday. --ado ------- zdump.c ------- *** /tmp/geta22604 Mon Nov 21 11:04:39 2005 --- /tmp/getb22604 Mon Nov 21 11:04:39 2005 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zdump.c 7.66"; /* ** This code has been made independent of the rest of the time --- 1,4 ---- ! static char elsieid[] = "@(#)zdump.c 7.68"; /* ** This code has been made independent of the rest of the time *************** *** 147,153 **** static int warned; static char * abbr P((struct tm * tmp)); ! static void abbrok P((const char * abbr, const char * zone)); static long delta P((struct tm * newp, struct tm * oldp)); static void dumptime P((const struct tm * tmp)); static time_t hunt P((char * name, time_t lot, time_t hit)); --- 147,153 ---- static int warned; static char * abbr P((struct tm * tmp)); ! static void abbrok P((const char * abbrp, const char * zone)); static long delta P((struct tm * newp, struct tm * oldp)); static void dumptime P((const struct tm * tmp)); static time_t hunt P((char * name, time_t lot, time_t hit)); *************** *** 194,201 **** #endif /* !defined TYPECHECK */ static void ! abbrok(abbr, zone) ! const char * const abbr; const char * const zone; { register const char * cp; --- 194,201 ---- #endif /* !defined TYPECHECK */ static void ! abbrok(abbrp, zone) ! const char * const abbrp; const char * const zone; { register const char * cp; *************** *** 203,217 **** if (warned) return; ! cp = abbr; wp = NULL; while (isascii(*cp) && isalpha(*cp)) ++cp; ! if (cp - abbr == 0) wp = _("lacks alphabetic at start"); ! if (cp - abbr < 3) wp = _("has fewer than 3 alphabetics"); ! if (cp - abbr > 6) wp = _("has more than 6 alphabetics"); if (wp == NULL && (*cp == '+' || *cp == '-')) { ++cp; --- 203,217 ---- if (warned) return; ! cp = abbrp; wp = NULL; while (isascii(*cp) && isalpha(*cp)) ++cp; ! if (cp - abbrp == 0) wp = _("lacks alphabetic at start"); ! if (cp - abbrp < 3) wp = _("has fewer than 3 alphabetics"); ! if (cp - abbrp > 6) wp = _("has more than 6 alphabetics"); if (wp == NULL && (*cp == '+' || *cp == '-')) { ++cp; *************** *** 225,232 **** return; (void) fflush(stdout); (void) fprintf(stderr, ! "%s: warning: zone \"%s\" abbreviation \"%s\" %s\n", ! progname, zone, abbr, wp); warned = TRUE; } --- 225,232 ---- return; (void) fflush(stdout); (void) fprintf(stderr, ! _("%s: warning: zone \"%s\" abbreviation \"%s\" %s\n"), ! progname, zone, abbrp, wp); warned = TRUE; } ------- backward ------- *** /tmp/geta22707 Mon Nov 21 11:06:10 2005 --- /tmp/getb22707 Mon Nov 21 11:06:10 2005 *************** *** 1,7 **** ! # @(#)backward 7.29 ! # This file provides links between current names for time zones ! # and their old names. Many names changed in late 1993. Link Africa/Bamako Africa/Timbuktu Link America/Argentina/Catamarca America/Argentina/ComodRivadavia --- 1,7 ---- ! # @(#)backward 7.30 ! # This file provides links and zones for old time zone names. ! # Many names changed in late 1993. Link Africa/Bamako Africa/Timbuktu Link America/Argentina/Catamarca America/Argentina/ComodRivadavia *************** *** 42,48 **** Link America/Noronha Brazil/DeNoronha Link America/Sao_Paulo Brazil/East Link America/Manaus Brazil/West - Link America/Chicago CST6CDT Link America/Halifax Canada/Atlantic Link America/Winnipeg Canada/Central Link America/Regina Canada/East-Saskatchewan --- 42,47 ---- *************** *** 55,62 **** Link America/Santiago Chile/Continental Link Pacific/Easter Chile/EasterIsland Link America/Havana Cuba - Link America/Panama EST - Link America/New_York EST5EDT Link Africa/Cairo Egypt Link Europe/Dublin Eire Link Europe/London Europe/Belfast --- 54,59 ---- *************** *** 67,73 **** Link Etc/GMT GMT-0 Link Etc/GMT GMT0 Link Etc/GMT Greenwich - Link Pacific/Honolulu HST Link Asia/Hong_Kong Hongkong Link Atlantic/Reykjavik Iceland Link Asia/Tehran Iran --- 64,69 ---- *************** *** 76,83 **** Link Asia/Tokyo Japan Link Pacific/Kwajalein Kwajalein Link Africa/Tripoli Libya - Link America/Phoenix MST - Link America/Denver MST7MDT Link America/Tijuana Mexico/BajaNorte Link America/Mazatlan Mexico/BajaSur Link America/Mexico_City Mexico/General --- 72,77 ---- *************** *** 85,91 **** Link Pacific/Chatham NZ-CHAT Link America/Denver Navajo Link Asia/Shanghai PRC - Link America/Los_Angeles PST8PDT Link Pacific/Pago_Pago Pacific/Samoa Link Pacific/Truk Pacific/Yap Link Europe/Warsaw Poland --- 79,84 ---- *************** *** 111,113 **** --- 104,119 ---- Link Etc/UTC Universal Link Europe/Moscow W-SU Link Etc/UTC Zulu + Zone AST4ADT -4:00 US A%sT + Zone EST5EDT -5:00 US E%sT + Zone CST6CDT -6:00 US C%sT + Zone MST7MDT -7:00 US M%sT + Zone PST8PDT -8:00 US P%sT + Zone YST9YDT -9:00 US Y%sT + Zone AST4 -4:00 - AST + Zone EST5 -5:00 - EST + Zone CST6 -6:00 - CST + Zone MST7 -7:00 - MST + Zone PST8 -8:00 - PST + Zone YST9 -9:00 - YST + Zone HST10 -10:00 - HST ------- systemv ------- *** /tmp/geta22751 Mon Nov 21 11:07:08 2005 --- /tmp/getb22751 Mon Nov 21 11:07:08 2005 *************** *** 1,4 **** ! # @(#)systemv 7.4 # Old rules, should the need arise. # No attempt is made to handle Newfoundland, since it cannot be expressed --- 1,4 ---- ! # @(#)systemv 7.5 # Old rules, should the need arise. # No attempt is made to handle Newfoundland, since it cannot be expressed *************** *** 7,13 **** # the change in the DST rules in the US in 1987 (which occurred before # the old rules were written). # ! # If you need the old rules, uncomment ## lines and comment-out Link lines. # Compile this *without* leap second correction for true conformance. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S --- 7,14 ---- # the change in the DST rules in the US in 1987 (which occurred before # the old rules were written). # ! # If you need the old rules, uncomment ## lines and ! # comment-out lines at the end of the file. # Compile this *without* leap second correction for true conformance. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S *************** *** 35,50 **** ## Zone SystemV/YST9 -9:00 - YST ## Zone SystemV/HST10 -10:00 - HST # For now... ! Link America/Halifax SystemV/AST4ADT ! Link America/New_York SystemV/EST5EDT ! Link America/Chicago SystemV/CST6CDT ! Link America/Denver SystemV/MST7MDT ! Link America/Los_Angeles SystemV/PST8PDT ! Link America/Anchorage SystemV/YST9YDT ! Link America/Puerto_Rico SystemV/AST4 ! Link America/Indiana/Indianapolis SystemV/EST5 ! Link America/Regina SystemV/CST6 ! Link America/Phoenix SystemV/MST7 ! Link Pacific/Pitcairn SystemV/PST8 ! Link Pacific/Gambier SystemV/YST9 ! Link Pacific/Honolulu SystemV/HST10 --- 36,51 ---- ## Zone SystemV/YST9 -9:00 - YST ## Zone SystemV/HST10 -10:00 - HST # For now... ! Zone SystemV/AST4ADT -4:00 US A%sT ! Zone SystemV/EST5EDT -5:00 US E%sT ! Zone SystemV/CST6CDT -6:00 US C%sT ! Zone SystemV/MST7MDT -7:00 US M%sT ! Zone SystemV/PST8PDT -8:00 US P%sT ! Zone SystemV/YST9YDT -9:00 US Y%sT ! Zone SystemV/AST4 -4:00 - AST ! Zone SystemV/EST5 -5:00 - EST ! Zone SystemV/CST6 -6:00 - CST ! Zone SystemV/MST7 -7:00 - MST ! Zone SystemV/PST8 -8:00 - PST ! Zone SystemV/YST9 -9:00 - YST ! Zone SystemV/HST10 -10:00 - HST

1 0

proposed tz changes for Georgia, Cuba, Azerbaijan
by Paul Eggert Nov. 18, 2005

Nov. 18, 2005

Here are proposed patches to the tz data. The current time stamps for Georgia and Cuba are incorrect, so I thought I'd package up the pending changes. * Georgia no longer observes DST, and has switched from +03 to +04. (Thanks to Teimuraz Abashidze for this info.) * Cuba is continuing its two-year experiment in year-round DST. (Thanks to Carlos A. Carnero Delgado for this info.) * Azerbaijan switches at 4:00 and 5:00, not at 1:00. (Thanks to Rustam Aliyev for this info.) * Some commentary fixes to record the most-recent Brazilian DST decrees. * Minor update of URLs in the tz-link web page. =================================================================== RCS file: RCS/asia,v retrieving revision 2005.14 retrieving revision 2005.14.0.1 diff -pu -r2005.14 -r2005.14.0.1 --- asia 2005/10/03 13:43:50 2005.14 +++ asia 2005/11/18 06:54:05 2005.14.0.1 @@ -99,9 +99,12 @@ Zone Asia/Yerevan 2:58:00 - LMT 1924 May 4:00 RussiaAsia AM%sT # Azerbaijan +# From Rustam Aliyev of the Azerbaijan Internet Forum (2005-10-23): +# According to the resolution of Cabinet of Ministers, 1997 +# Resolution available at: http://aif.az/docs/daylight_res.pdf # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule Azer 1997 max - Mar lastSun 1:00 1:00 S -Rule Azer 1997 max - Oct lastSun 1:00 0 - +Rule Azer 1997 max - Mar lastSun 4:00 1:00 S +Rule Azer 1997 max - Oct lastSun 5:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Baku 3:19:24 - LMT 1924 May 2 3:00 - BAKT 1957 Mar # Baku Time @@ -348,6 +351,17 @@ Link Asia/Nicosia Europe/Nicosia # Mikhail Saakashvili, who said the change was partly prompted by the process # of integration into Europe. +# From Teimuraz Abashidze (2005-11-07): +# Government of Georgia ... decided to NOT CHANGE daylight savings time on +# [Oct.] 30, as it was done before during last more than 10 years. +# Currently, we are in fact GMT +4:00, as before 30 October it was GMT +# +3:00.... The problem is, there is NO FORMAL LAW or governmental document +# about it. As far as I can find, I was told, that there is no document, +# because we just DIDN'T ISSUE document about switching to winter time.... +# I don't know what can be done, especially knowing that some years ago our +# DST rules where changed THREE TIMES during one month. + + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tbilisi 2:59:16 - LMT 1880 2:59:16 - TBMT 1924 May 2 # Tbilisi Mean Time @@ -359,7 +373,8 @@ Zone Asia/Tbilisi 2:59:16 - LMT 1880 4:00 E-EurAsia GE%sT 1996 Oct lastSun 4:00 1:00 GEST 1997 Mar lastSun 4:00 E-EurAsia GE%sT 2004 Jun 27 - 3:00 RussiaAsia GE%sT + 3:00 RussiaAsia GE%sT 2005 Mar lastSun 2:00 + 4:00 - GET # East Timor =================================================================== RCS file: RCS/northamerica,v retrieving revision 2005.14 retrieving revision 2005.14.0.1 diff -pu -r2005.14 -r2005.14.0.1 --- northamerica 2005/10/03 13:43:50 2005.14 +++ northamerica 2005/11/18 06:54:05 2005.14.0.1 @@ -1815,6 +1815,11 @@ Zone America/Costa_Rica -5:36:20 - LMT 1 # to normal hours (after daylight saving time)". # For now, let's assume that it's a one-year temporary measure. +# From Carlos A. Carnero Delgado (2005-11-12): +# This year (just like in 2004-2005) there's no change in time zone +# adjustment in Cuba. We will stay in daylight saving time: +# http://www.granma.cu/espanol/2005/noviembre/mier9/horario.html + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Cuba 1928 only - Jun 10 0:00 1:00 D Rule Cuba 1928 only - Oct 10 0:00 0 S @@ -1845,7 +1850,7 @@ Rule Cuba 1997 only - Oct 12 0:00s 0 S Rule Cuba 1998 1999 - Mar lastSun 0:00s 1:00 D Rule Cuba 1998 2003 - Oct lastSun 0:00s 0 S Rule Cuba 2000 max - Apr Sun>=1 0:00s 1:00 D -Rule Cuba 2005 max - Oct lastSun 0:00s 0 S +Rule Cuba 2006 max - Oct lastSun 0:00s 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Havana -5:29:28 - LMT 1890 =================================================================== RCS file: RCS/southamerica,v retrieving revision 2005.14 retrieving revision 2005.14.0.1 diff -pu -r2005.14 -r2005.14.0.1 --- southamerica 2005/10/03 13:43:50 2005.14 +++ southamerica 2005/11/18 06:54:05 2005.14.0.1 @@ -565,11 +565,12 @@ Rule Brazil 2003 only - Oct 19 0:00 1:0 # Decree 5,223 (2004-10-01) reestablishes DST in MT. # <a href="http://www.planalto.gov.br/ccivil_03/_Ato2004-2006/2004/Decreto/D5223.htm"></a> Rule Brazil 2004 only - Nov 2 0:00 1:00 S +# Decree <a href="http://pcdsh01.on.br/DecHV5539.gif">5,539</a> (2005-09-19), +# adopted by the same states as before. +Rule Brazil 2005 max - Oct Sun>=15 0:00 1:00 S # The latest ruleset listed above says that the following states observe DST: # DF, ES, GO, MG, MS, MT, PR, RJ, RS, SC, SP. -# -Rule Brazil 2005 max - Oct Sun>=15 0:00 1:00 S -# For dates after mid-2005, the above rules with TO="max" are guesses +# For dates after mid-2006, the above rules with TO="max" are guesses # and are quite possibly wrong, but are more likely than no DST at all. =================================================================== RCS file: RCS/tz-link.htm,v retrieving revision 2005.14 retrieving revision 2005.14.0.1 diff -pu -r2005.14 -r2005.14.0.1 --- tz-link.htm 2005/10/03 13:43:50 2005.14 +++ tz-link.htm 2005/11/18 07:44:33 2005.14.0.1 @@ -9,7 +9,7 @@ <meta http-equiv="Content-type" content='text/html; charset="US-ASCII"' /> <meta name="DC.Creator" content="Eggert, Paul" /> <meta name="DC.Contributor" content="Olson, Arthur David" /> -<meta name="DC.Date" content="2005-09-25" /> +<meta name="DC.Date" content="2005-11-17" /> <meta name="DC.Description" content="Sources of information about time zones and daylight saving time" /> <meta name="DC.Identifier" content="http://www.twinsun.com/tz/tz-link.htm" /> @@ -114,7 +114,7 @@ Here are some recent links that may be o </p> <h2>Web pages using recent versions of the <code>tz</code> database</h2> <ul> -<li><a href="http://twiki.org/cgi-bin/xtra/tzdate">Date and Time Gateway</a> +<li><a href="http://twiki.org/cgi-bin/xtra/tzdatepick.html">Date and Time Gateway</a> is a text-based point-and-click interface to tables of current time throughout the world.</li> <li>Fancier web interfaces, roughly in ascending order of complexity, include: @@ -152,8 +152,8 @@ href="http://www.w3.org/2002/12/cal/#tzd data</a> converted from <code>tz</code>. An earlier <a href="http://www.w3.org/2000/01/foo">schema</a> was sketched out.</li> <li><a -href="http://inet-consulting.com/draft-royer-calsch-xcal-01.txt"><abbr -title="iCalendar in XML Format">xCal</abbr></a> +href="ftp://ftp.rfc-editor.org/internet-drafts/draft-royer-calsch-xcal-03.txt"><abbr +title="iCalendar in XML Format">xCal-Basic</abbr></a> is a draft <a href="http://www.w3.org/XML/"><abbr title="Extensible Markup Language">XML</abbr></a> document type

1 0

FW: Cuba TZ update
by Olson, Arthur David (NIH/NCI) Nov. 14, 2005

Nov. 14, 2005

Carlos A. Carnero Delgado is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Carlos A. Carnero Delgado [mailto:carlos@carnero.ca] Sent: Saturday, November 12, 2005 2:31 AM To: tz(a)lecserver.nci.nih.gov Subject: Cuba TZ update Hello, this year (just like in 2004-2005) there's no change in time zone adjustment in Cuba. We will stay in daylight savings time: http://www.granma.cu/espanol/2005/noviembre/mier9/horario.html. Roughly, this says that the cause for not changing back is of electrical power & fuel savings nature. I have patched my FreeBSD workstation with the attached diff that I made, and AFAICT, this works locally. Can you please confirm and maybe merge into the TZ database? Thanks a lot, Carlos.

2 1

FW: Changes in time zone configuration for Cuba
by Olson, Arthur David (NIH/NCI) Nov. 14, 2005

Nov. 14, 2005

José Angel Rodríguez Leyva is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: José Angel Rodríguez Leyva [mailto:jar@villazul.ltu.sld.cu] Sent: Sunday, November 13, 2005 3:39 PM To: tz(a)lecserver.nci.nih.gov Subject: Changes in time zone configuration for Cuba Hello, Cuba keeps Daylight saving time this year again, for a similar reason than last year. I have to make the changes in Cuba timezone file and I send to you. Sorry for my english. Greeting José A. Rodríguez # Cuba # From Arthur David Olson (1999-03-29): # The 1999-03-28 exhibition baseball game held in Havana, Cuba, between # the Cuban National Team and the Baltimore Orioles was carried live on # the Orioles Radio Network, including affiliate WTOP in Washington, DC. # During the game, play-by-play announcer Jim Hunter noted that # "We'll be losing two hours of sleep...Cuba switched to Daylight Saving # Time today." (The "two hour" remark referred to losing one hour of # sleep on 1999-03-28--when the announcers were in Cuba as it switched # to DST--and one more hour on 1999-04-04--when the announcers will have # returned to Baltimore, which switches on that date.) # From Evert van der Veer via Steffen Thorsen (2004-10-28): # Cuba is not going back to standard time this year. # From Paul Eggert (2004-10-28): # http://www.granma.cu/ingles/2004/septiembre/juev30/41medid-i.html # says that it's due to a problem at the Antonio Guiteras # thermoelectric plant, and says "This October there will be no return # to normal hours (after daylight saving time)". # For now, let's assume that it's a one-year temporary measure. # 2005-Oct-29 # Cuba keeps again Daylight Saving Time this year. Assumed two-years # temporary. # http://granma.co.cu/2005/11/09/nacional/artic09.html # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Cuba 1928 only - Jun 10 0:00 1:00 D Rule Cuba 1928 only - Oct 10 0:00 0 S Rule Cuba 1940 1942 - Jun Sun>=1 0:00 1:00 D Rule Cuba 1940 1942 - Sep Sun>=1 0:00 0 S Rule Cuba 1945 1946 - Jun Sun>=1 0:00 1:00 D Rule Cuba 1945 1946 - Sep Sun>=1 0:00 0 S Rule Cuba 1965 only - Jun 1 0:00 1:00 D Rule Cuba 1965 only - Sep 30 0:00 0 S Rule Cuba 1966 only - May 29 0:00 1:00 D Rule Cuba 1966 only - Oct 2 0:00 0 S Rule Cuba 1967 only - Apr 8 0:00 1:00 D Rule Cuba 1967 1968 - Sep Sun>=8 0:00 0 S Rule Cuba 1968 only - Apr 14 0:00 1:00 D Rule Cuba 1969 1977 - Apr lastSun 0:00 1:00 D Rule Cuba 1969 1971 - Oct lastSun 0:00 0 S Rule Cuba 1972 1974 - Oct 8 0:00 0 S Rule Cuba 1975 1977 - Oct lastSun 0:00 0 S Rule Cuba 1978 only - May 7 0:00 1:00 D Rule Cuba 1978 1990 - Oct Sun>=8 0:00 0 S Rule Cuba 1979 1980 - Mar Sun>=15 0:00 1:00 D Rule Cuba 1981 1985 - May Sun>=5 0:00 1:00 D Rule Cuba 1986 1989 - Mar Sun>=14 0:00 1:00 D Rule Cuba 1990 1997 - Apr Sun>=1 0:00 1:00 D Rule Cuba 1991 1995 - Oct Sun>=8 0:00s 0 S Rule Cuba 1996 only - Oct 6 0:00s 0 S Rule Cuba 1997 only - Oct 12 0:00s 0 S Rule Cuba 1998 1999 - Mar lastSun 0:00s 1:00 D Rule Cuba 1998 2003 - Oct lastSun 0:00s 0 S Rule Cuba 2000 max - Apr Sun>=1 0:00s 1:00 D Rule Cuba 2006 max - Oct lastSun 0:00s 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Havana -5:29:28 - LMT 1890 -5:29:36 - HMT 1925 Jul 19 12:00 # Havana MT -5:00 Cuba C%sT

1 0

Changes in time zone configuration for Cuba
by José Angel Rodríguez Leyva Nov. 13, 2005

Nov. 13, 2005

Hello, Cuba keeps Daylight saving time this year again, for a similar reason than last year. I have to make the changes in Cuba timezone file and I send to you. Sorry for my english. Greeting José A. Rodríguez

1 0

Cuba TZ update
by Carlos A. Carnero Delgado Nov. 12, 2005

Nov. 12, 2005

Hello, this year (just like in 2004-2005) there's no change in time zone adjustment in Cuba. We will stay in daylight savings time: http://www.granma.cu/espanol/2005/noviembre/mier9/horario.html. Roughly, this says that the cause for not changing back is of electrical power & fuel savings nature. I have patched my FreeBSD workstation with the attached diff that I made, and AFAICT, this works locally. Can you please confirm and maybe merge into the TZ database? Thanks a lot, Carlos.

1 0

Duration for a new zoneinfo file
by Rest Matthias Nov. 9, 2005

Nov. 9, 2005

Hello, At the moment we have the situation that in the country of some customers the head of these countries decides to change the time/date for changing of winter/summertime. Now I would like to know how long it would approximately need until a new zoneinfo file is created after you received a message that there will be a change? This is important for us, because SUN is using your zoneinfo files as input for JAVA which we are using. Thanks for your help. Kind Regards, Matthias Rest

1 0

FW: [Fwd: Feedback on zone translations]
by Olson, Arthur David (NIH/NCI) Nov. 8, 2005

Nov. 8, 2005

Mark Davis is on the time zone list, but at a different address than that shown below. --ado -----Original Message----- From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Tuesday, November 08, 2005 1:53 PM To: tz(a)lecserver.nci.nih.gov Subject: [Fwd: Feedback on zone translations] The CLDR committee is looking for feedback on certain aspects of zone translation raised in the document listed below. In particular, we'd appreciate feedback on Brazil, Argentina, and Russia. http://unicode.org/cldr/data/dropbox/instructions.html Mark

1 0

[Fwd: Feedback on zone translations]
by Mark Davis Nov. 8, 2005

Nov. 8, 2005

The CLDR committee is looking for feedback on certain aspects of zone translation raised in the document listed below. In particular, we'd appreciate feedback on Brazil, Argentina, and Russia. http://unicode.org/cldr/data/dropbox/instructions.html Mark

1 0

FW: DST rules change for Georgia
by Olson, Arthur David (NIH/NCI) Nov. 7, 2005

Nov. 7, 2005

Teimuraz Abashidze is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Teimuraz Abashidze (IT) [mailto:tabashidze@geocell.com.ge] Sent: Monday, November 07, 2005 8:06 AM To: tz(a)lecserver.nci.nih.gov Subject: DST rules change for Georgia Hello tz(a)elsie.nci.nih.gov, Dear sir! I've posted on bugzilla new bug #172279, and they told me to contact you: You need to discuss this with upstream, i.e. tz(a)elsie.nci.nih.gov When upstream accepts a change and incorporates it, we'll then update our packages. But as a rule for tzdata we use the timezone data unmodified from upstream. Description of problem: It's not actually a BUG. Government of Georgia (ExUSSR, Caucasia, capital city Tbilisi) decided to NOT CHANGE daylight sayvings time at 30 Sep. night, as it was done before during last more than 10 years. Currently, we are in fact GMT +4:00, as before 30 October it was GMT +3:00. Currently http://www.worldtimeserver.com/current_time_in_GE.aspx shows correct time for us. The problem is, there is NO FORMAL LAW or governmental document about it. A sfar as I can find, I was told, that there is no document, because we just DIDN'T ISSUE document about swithching to winter time".... I don't know waht can be done, especially knowing, that some years ago our DST rules where changed THREE TIMES during one month... Maybe it's stupid, but maybe it's possible to create TWO separate time zones for Georgia, one with DST settings, one withought? I could't find a way to disable DST in Linux otherwise... BTW, of course it's not related to Fedora Core or any particular distribution, this problem shoul be common for all of them... Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Set timezone to Asia/Georgia 2. 3. Actual Results: #date Wed Nov 2 14:56:44 GET 2005 # Expected Results: #date Wed Nov 2 15:56:44 GET 2005 # Best regards, Teimuraz Abashidze Enterprise Network Manager Information Technologies Geocell Ltd. Phone: (995 32) 770100 (ext.7702) Fax: (995 32) 770107 GSM: (995 77) 458001 E-mail: tabashidze(a)geocell.com.ge --------------------------------------------- This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. GEOCELL makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not necessarily reflect the opinions of GEOCELL.

1 0