- tz - lists.iana.org

Proposed change to "systemv" file
by Olson, Arthur David (NIH/NCI) Oct. 3, 2005

Oct. 3, 2005

The attached change avoids a "link-to-a-link" situation in the "systemv" data file. --ado ------- systemv ------- *** /tmp/geta2174 Mon Oct 3 09:56:37 2005 --- /tmp/getb2174 Mon Oct 3 09:56:37 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 *************** *** 42,48 **** 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 --- 42,48 ---- 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

1 0

Tzcode2005n.tar.gz and tzdata2005n.tar.gz
by Olson, Arthur David (NIH/NCI) Oct. 3, 2005

Oct. 3, 2005

The files... ftp://elsie.nci.nih.gov/pub/tzcode2005n.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2005n.tar.gz ...are now available; these reflect the changes circulated last week on the time zone mailing list by Paul Eggert (both the Uruguary changes and the Kyrgyzstan et al. changes). --ado

1 0

FW: proposed tz patch for Uruguay
by Olson, Arthur David (NIH/NCI) Oct. 3, 2005

Oct. 3, 2005

-----Original Message----- From: Paul Eggert [mailto:eggert@CS.UCLA.EDU] Sent: Friday, September 30, 2005 1:53 AM To: ec-acd(a)dedicado.net.uy Cc: tz(a)lecserver.nci.nih.gov Subject: proposed tz patch for Uruguay > From: Eduardo [mailto:ec-acd@dedicado.net.uy] > Date: 27 Sep 2005 17:02 > The uruguayan government has decreed a change in the local time. Thanks for letting us know about that. This takes effect October 9 so we should get this out the door. Here's a proposed patch to the tz database (basically, the change you mentioned, along with some commentary). This is in addition to the patch I circulated on this list on September 25 for Kyrgyzstan. =================================================================== RCS file: RCS/southamerica,v retrieving revision 2005.12 retrieving revision 2005.12.0.1 diff -pu -r2005.12 -r2005.12.0.1 --- southamerica 2005/08/22 16:05:26 2005.12 +++ southamerica 2005/09/30 05:45:43 2005.12.0.1 @@ -1055,6 +1055,12 @@ Rule Uruguay 2004 only - Sep 19 0:00 1: # save energy ... it was postponed two weeks.... # http://www.presidencia.gub.uy/_Web/noticias/2005/03/2005031005.htm Rule Uruguay 2005 only - Mar 27 2:00 0 - +# From Eduardo Cota (2005-09-27): +# +http://www.presidencia.gub.uy/_Web/decretos/2005/09/CM%20119_09%2009%20 +2005_00001.PDF # This means that from 2005-10-09 at 02:00 local time, +until 2006-03-12 at # 02:00 local time, official time in Uruguay will +be at GMT -2. +Rule Uruguay 2005 only - Oct 9 2:00 1:00 S +Rule Uruguay 2006 only - Mar 12 2:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Montevideo -3:44:44 - LMT 1898 Jun 28 -3:44:44 - MMT 1920 May 1 # Montevideo MT

1 0

RE: tznext 64-bit timezones - Comments
by Olson, Arthur David (NIH/NCI) Sept. 27, 2005

Sept. 27, 2005

> Invoking zdump -v...showed many timezones with behavior differences in the early transitions. For example Africa/Addis_Ababa and US/Pacific: Good catch! This happens because, when dealing with instants before the first transition time recorded in a time zone file, "localtime" assumes that the time type to use is the first type that's a "standard time" type. When we're running on a 64-bit system we can deal with instants prior to 1901, but we want to ignore such information when writing the 32-bit portion of the data file to avoid having localtime make the wrong assumption. I've attached a change to the "experimental" version of zic.c (sent around in June on the time zone mailing list) that should address the problem. Note that we end up with very slightly smaller time zone binary files with the change in place. > It might be nice to add an option to zdump to print out the POSIX TZ equivalent for the timezone. Nice yes; not so straightforward. Recall that zdump (very deliberately) knows nothing about the format of time zone data files; it simply makes repeated calls to localtime, looks for unexpected shifts in the return values, and prints information about the instants at which shifts occur. With the "experimental" time zone data files, it is possible to use a script such as... #! /bin/sh ZONEINFODIR=$HOME/src/tzexp2/tmp/etc/zoneinfo for file in `find $ZONEINFODIR -type f -print` do tail -1 $file | sed "s@^@$file: @" done ...to print the equivalents. --ado ------- zic.c ------- *** /tmp/geta7744 Tue Sep 27 16:52:10 2005 --- /tmp/getb7744 Tue Sep 27 16:52:10 2005 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zic.c 7.149"; #include "private.h" #include "locale.h" --- 1,4 ---- ! static char elsieid[] = "@(#)zic.c 7.150"; #include "private.h" #include "locale.h" *************** *** 1584,1589 **** --- 1584,1592 ---- register int thistimei, thistimecnt; register int thisleapi, thisleapcnt; register int thistimelim, thisleaplim; + int writetype[TZ_MAX_TIMES]; + int typemap[TZ_MAX_TYPES]; + register int thistypecnt; if (pass == 1) { thistimei = timei32; *************** *** 1598,1613 **** } thistimelim = thistimei + thistimecnt; thisleaplim = thisleapi + thisleapcnt; #define DO(field) (void) fwrite((void *) tzh.field, \ (size_t) sizeof tzh.field, (size_t) 1, fp) tzh = tzh0; (void) strncpy(tzh.tzh_magic, TZ_MAGIC, sizeof tzh.tzh_magic); tzh.tzh_version[0] = ZIC_VERSION; ! convert(eitol(typecnt), tzh.tzh_ttisgmtcnt); ! convert(eitol(typecnt), tzh.tzh_ttisstdcnt); convert(eitol(thisleapcnt), tzh.tzh_leapcnt); convert(eitol(thistimecnt), tzh.tzh_timecnt); ! convert(eitol(typecnt), tzh.tzh_typecnt); convert(eitol(charcnt), tzh.tzh_charcnt); DO(tzh_magic); DO(tzh_version); --- 1601,1624 ---- } thistimelim = thistimei + thistimecnt; thisleaplim = thisleapi + thisleapcnt; + for (i = 0; i < typecnt; ++i) + writetype[i] = FALSE; + for (i = thistimei - 1; i < thistimelim; ++i) + if (i >= 0) + writetype[types[i]] = TRUE; + thistypecnt = 0; + for (i = 0; i < typecnt; ++i) + typemap[i] = writetype[i] ? thistypecnt++ : -1; #define DO(field) (void) fwrite((void *) tzh.field, \ (size_t) sizeof tzh.field, (size_t) 1, fp) tzh = tzh0; (void) strncpy(tzh.tzh_magic, TZ_MAGIC, sizeof tzh.tzh_magic); tzh.tzh_version[0] = ZIC_VERSION; ! convert(eitol(thistypecnt), tzh.tzh_ttisgmtcnt); ! convert(eitol(thistypecnt), tzh.tzh_ttisstdcnt); convert(eitol(thisleapcnt), tzh.tzh_leapcnt); convert(eitol(thistimecnt), tzh.tzh_timecnt); ! convert(eitol(thistypecnt), tzh.tzh_typecnt); convert(eitol(charcnt), tzh.tzh_charcnt); DO(tzh_magic); DO(tzh_version); *************** *** 1623,1638 **** if (pass == 1) puttzcode((long) ats[i], fp); else puttzcode64(ats[i], fp); ! if (thistimecnt > 0) ! (void) fwrite((void *) &types[thistimei], ! (size_t) sizeof types[0], ! (size_t) thistimecnt, fp); - for (i = 0; i < typecnt; ++i) { - puttzcode(gmtoffs[i], fp); - (void) putc(isdsts[i], fp); - (void) putc(abbrinds[i], fp); } if (charcnt != 0) (void) fwrite((void *) chars, (size_t) sizeof chars[0], (size_t) charcnt, fp); --- 1634,1654 ---- if (pass == 1) puttzcode((long) ats[i], fp); else puttzcode64(ats[i], fp); ! for (i = thistimei; i < thistimelim; ++i) { ! unsigned char uc; ! ! uc = typemap[types[thistimei]]; ! (void) fwrite((void *) &uc, ! (size_t) sizeof uc, ! (size_t) 1, fp); } + for (i = 0; i < typecnt; ++i) + if (writetype[i]) { + puttzcode(gmtoffs[i], fp); + (void) putc(isdsts[i], fp); + (void) putc(abbrinds[i], fp); + } if (charcnt != 0) (void) fwrite((void *) chars, (size_t) sizeof chars[0], (size_t) charcnt, fp); *************** *** 1662,1670 **** puttzcode(corr[i], fp); } for (i = 0; i < typecnt; ++i) ! (void) putc(ttisstds[i], fp); for (i = 0; i < typecnt; ++i) ! (void) putc(ttisgmts[i], fp); } (void) fprintf(fp, "\n%s\n", string); if (ferror(fp) || fclose(fp)) { --- 1678,1688 ---- puttzcode(corr[i], fp); } for (i = 0; i < typecnt; ++i) ! if (writetype[i]) ! (void) putc(ttisstds[i], fp); for (i = 0; i < typecnt; ++i) ! if (writetype[i]) ! (void) putc(ttisgmts[i], fp); } (void) fprintf(fp, "\n%s\n", string); if (ferror(fp) || fclose(fp)) {

1 0

FW: Change in Uruguay time zone
by Olson, Arthur David (NIH/NCI) Sept. 27, 2005

Sept. 27, 2005

Eduardo Cota is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Eduardo [mailto:ec-acd@dedicado.net.uy] Sent: Tuesday, September 27, 2005 5:02 PM To: tz(a)lecserver.nci.nih.gov Subject: Fw: Change in Uruguay time zone If no one has yet reported this ... (did not see it in the latest time zone data): The uruguayan government has decreed a change in the local time. The decree in the government's web site (in Spanish): http://www.presidencia.gub.uy/_Web/decretos/2005/09/CM%20119_09%2009%202005_ 00001.PDF This means that from 9 October 2005 at 2:00 local time, until 12 March 2006 at 2:00 local time, official time in Uruguay will be at GMT -2 This means that the file "zoneinfo/southamerica" should be changed. I assume the change must be to add the following 2 lines Rule Uruguay 2005 only - Oct 9 2:00 1:00 S Rule Uruguay 2006 only - Mar 12 2:00 0 - I am no authority in Uruguay, just a timezone user. Yours, Eduardo Cota.

1 0

Fw: Change in Uruguay time zone
by Eduardo Sept. 27, 2005

Sept. 27, 2005

If no one has yet reported this ... (did not see it in the latest time zone data): The uruguayan government has decreed a change in the local time. The decree in the government's web site (in Spanish): http://www.presidencia.gub.uy/_Web/decretos/2005/09/CM%20119_09%2009%202005… This means that from 9 October 2005 at 2:00 local time, until 12 March 2006 at 2:00 local time, official time in Uruguay will be at GMT -2 This means that the file "zoneinfo/southamerica" should be changed. I assume the change must be to add the following 2 lines Rule Uruguay 2005 only - Oct 9 2:00 1:00 S Rule Uruguay 2006 only - Mar 12 2:00 0 - I am no authority in Uruguay, just a timezone user. Yours, Eduardo Cota.

1 0

FW: tznext 64-bit timezones - Comments
by Olson, Arthur David (NIH/NCI) Sept. 27, 2005

Sept. 27, 2005

-----Original Message----- From: Robbin Kawabata [mailto:Robbin.Kawabata@eng.sun.com] Sent: Friday, September 23, 2005 12:09 PM To: ... Cc: robbin.kawabata(a)sun.com Subject: tznext 64-bit timezones - Comments Here's some feedback on the 64-bit times proposal dated 6/30/05. 1. New (TZif2) vs. old (TZif) format zoneinfo files and old localtime() To check how an old localtime() would behave with timezones compiled with tznext zic.c, I compared zdump behavior using these combinations: zoneinfo data version of zic localtime() files used to compile version zoneinfo files -------------- ----------------- ----------- a. tzdata2005k zic.c - 2005k 2005k b. tzdata2005k zic.c - tznext 2005k Invoking zdump -v (32-bit) against the timezones for combinations a. vs. b. showed many timezones with behavior differences in the early transitions. For example Africa/Addis_Ababa and US/Pacific: 1,3c1,3 < Africa/Addis_Ababa Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 23:21:12 1901 AD MT isdst=0 < Africa/Addis_Ababa Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 23:21:12 1901 AD MT isdst=0 < Africa/Addis_Ababa Mon May 4 21:24:39 1936 UTC = Mon May 4 23:59:59 1936 AD MT isdst=0 --- > Africa/Addis_Ababa Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 23:20:40 > 1901 LM T isdst=0 > Africa/Addis_Ababa Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 23:20:40 > 1901 LM T isdst=0 > Africa/Addis_Ababa Mon May 4 21:24:39 1936 UTC = Mon May 4 23:59:27 > 1936 LM T isdst=0 1,3c1,3 < US/Pacific Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 12:45:52 1901 PST isdst= 0 < US/Pacific Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 12:45:52 1901 PST isdst= 0 < US/Pacific Sun Mar 31 09:59:59 1918 UTC = Sun Mar 31 01:59:59 1918 PST isdst= 0 --- > US/Pacific Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 12:52:54 1901 > LMT isdst= 0 > US/Pacific Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 12:52:54 1901 > LMT isdst= 0 > US/Pacific Sun Mar 31 09:59:59 1918 UTC = Sun Mar 31 02:07:01 1918 > LMT isdst= 0 Also note 32-bit vs. 64-bit zdump/localtime() behave differently with the tznext zoneinfo files. (The 64-bit 2005k localtime() behavior seems OK.) /* Problem - 32-bit */ % ./sparc/zdump -v -c 1901,1919 US/Pacific US/Pacific Tue Sep 20 18:27:45 2005 UTC = Tue Sep 20 11:27:45 2005 PDT isdst=1 US/Pacific Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 12:52:54 1901 LMT isdst=0 US/Pacific Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 12:52:54 1901 LMT isdst=0 US/Pacific Sun Mar 31 09:59:59 1918 UTC = Sun Mar 31 02:07:01 1918 LMT isdst=0 US/Pacific Sun Mar 31 10:00:00 1918 UTC = Sun Mar 31 03:00:00 1918 PDT isdst=1 US/Pacific Sun Oct 27 08:59:59 1918 UTC = Sun Oct 27 01:59:59 1918 PDT isdst=1 US/Pacific Sun Oct 27 09:00:00 1918 UTC = Sun Oct 27 01:00:00 1918 PST isdst=0 US/Pacific Tue Jan 19 03:14:07 2038 UTC = Mon Jan 18 19:14:07 2038 PST isdst=0 US/Pacific Mon Jan 18 03:14:07 2038 UTC = Sun Jan 17 19:14:07 2038 PST isdst=0 /* OK - 64-bit */ % ./sparcv9/zdump -v -c 1901,1919 US/Pacific US/Pacific Tue Sep 20 18:27:24 2005 UTC = Tue Sep 20 11:27:24 2005 PDT isdst=1 US/Pacific -9223372036854775808 = NULL US/Pacific -9223372036854689408 = NULL US/Pacific Sun Mar 31 09:59:59 1918 UTC = Sun Mar 31 01:59:59 1918 PST isdst=0 US/Pacific Sun Mar 31 10:00:00 1918 UTC = Sun Mar 31 03:00:00 1918 PDT isdst=1 US/Pacific Sun Oct 27 08:59:59 1918 UTC = Sun Oct 27 01:59:59 1918 PDT isdst=1 US/Pacific Sun Oct 27 09:00:00 1918 UTC = Sun Oct 27 01:00:00 1918 PST isdst=0 US/Pacific 9223372036854775807 = NULL US/Pacific 9223372036854689407 = NULL /* OK - 64-bit */ % ./sparcv9/zdump -v -c 1880,1919 US/Pacific US/Pacific Tue Sep 20 18:32:29 2005 UTC = Tue Sep 20 11:32:29 2005 PDT isdst=1 US/Pacific -9223372036854775808 = NULL US/Pacific -9223372036854689408 = NULL US/Pacific Sun Nov 18 19:59:59 1883 UTC = Sun Nov 18 12:07:01 1883 LMT isdst=0 US/Pacific Sun Nov 18 20:00:00 1883 UTC = Sun Nov 18 12:00:00 1883 PST isdst=0 US/Pacific Sun Mar 31 09:59:59 1918 UTC = Sun Mar 31 01:59:59 1918 PST isdst=0 US/Pacific Sun Mar 31 10:00:00 1918 UTC = Sun Mar 31 03:00:00 1918 PDT isdst=1 US/Pacific Sun Oct 27 08:59:59 1918 UTC = Sun Oct 27 01:59:59 1918 PDT isdst=1 US/Pacific Sun Oct 27 09:00:00 1918 UTC = Sun Oct 27 01:00:00 1918 PST isdst=0 US/Pacific 9223372036854775807 = NULL US/Pacific 9223372036854689407 = NULL 2. tznext approach This how I think the tznext approach works. Please correct as needed. a. If the timezone has a POSIX TZ equivalent, then: a1. zic - zic writes 64-bit transitions to the second part of the zoneinfo file (after the second TZif2 header) for times between the lowest year through the highest year specified in the rules for the timezone. If the highest year in the rules is less than 2037, 2037 is used as the highest year. This section can accomodate transitions outside the range of years 1901-2037. a2. localtime() - When a timezone is newly loaded, the POSIX TZ equivalent is used to generate ~400 (more?) years (into the future) worth of transitions into a table (see tzload()->tzparse()). Then localtime() uses the 400-year cycle approach to calculate transitions in the future that are outside the transition table. a3. far past times - zic can exit with "too many transitions" error if the rules define transitions for very early years (eg, "min") which would cause zic to overflow the 1200 entry transition table. Note, none of the timezones in the current timezone source files use "min". An example of rules that could generate this error is the commented-out SystemV rules in the systemv source file. b. If the timezone does not have a POSIX TZ equivalent, then: b1. zic - the 64-bit transition table in the second part of the zoneinfo file (after the second TZif2 header) has transitions for the period from 400 years before the lowest year, through 400 years after the highest year, where the years are specified in the rules for the timezone. This section can accomodate transitions outside the range of years 1901-2037. b2. localtime() - localtime() uses the 400-year cycle approach to calculate times outside the range of the transition table. b3. far past times - zic can handle the "min" keyword for timezones that do not have a POSIX TZ equivalent, because for these timezones, zic creates a 400-year transition table for far past times. 3. zic - "min" keyword Since zic can now issue an error with "min", and since min is described on zic.1 man page, perhaps we should: - Change zic to use a lower bounds year for "min" if it encounters the table overrun condition. zic should issue a warning if this occurs. Document this behavior on the zic man page. or - Just document the limitation with "min" on the zic man page. In the Notes section suggest a workaround to change "min" to a lower year value. 4. zdump It might be nice to add an option to zdump to print out the POSIX TZ equivalent for the timezone.

1 0

proposed tz patch for Kyrgyzstan, etc.
by Paul Eggert Sept. 25, 2005

Sept. 25, 2005

Malik Abdugaliev writes that the tz database is already incorrect for the tm_isdst flag in Kyrgyzstan, and will report the wrong UTC offset for time stamps starting October 30. Here's a patch for this, along with some commentary and URL fixes that I had saved up. Patches affecting data: * Kyrgyzstan stopped observing DST on August 12. Thanks to Malik Abdugaliev for this info. Commentary changes: * Spell "Kygyzstan" and "Kyrgyz" consistently. * Add more info about times of ships at sea, taken from Wikipedia. * Add a comment about a few towns in Alabama that observe Eastern time, even though legal time is Central. As far as we know the practice has been going on for some time, and they can use TZ='America/New_York'. URL changes in tz-link.htm: * Restore pointer to <http://www.energy.ca.gov/daylightsaving.html>, since that web page is being updated again. * Remove pointers to these no-longer-working locations: http://time.world-stay.com/ http://www.lawlink.nsw.gov.au/Lawlink/Corporate/ll_corporate.nsf/pages/atto… * Update URLs that were moved or forwarded. =================================================================== RCS file: RCS/asia,v retrieving revision 2005.13 retrieving revision 2005.13.0.2 diff -pu -r2005.13 -r2005.13.0.2 --- asia 2005/08/29 15:54:31 2005.13 +++ asia 2005/09/25 23:51:17 2005.13.0.2 @@ -1044,18 +1044,22 @@ Zone Asia/Oral 3:25:24 - LMT 1924 May 2 # <http://eng.gateway.kg/cgi-bin/page.pl?id=1&story_name=doc9979.shtml> # Kyrgyzstan is canceling the daylight saving time system. I take the article # to mean that they will leave their clocks at 6 hours ahead of UTC. +# From Malik Abdugaliev (2005-09-21): +# Our government cancels daylight saving time 6th of August 2005. +# From 2005-08-12 our GMT-offset is +6, w/o any daylight saving. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule Kirgiz 1992 1996 - Apr Sun>=7 0:00s 1:00 S -Rule Kirgiz 1992 1996 - Sep lastSun 0:00 0 - -Rule Kirgiz 1997 max - Mar lastSun 2:30 1:00 S -Rule Kirgiz 1997 max - Oct lastSun 2:30 0 - +Rule Kyrgyz 1992 1996 - Apr Sun>=7 0:00s 1:00 S +Rule Kyrgyz 1992 1996 - Sep lastSun 0:00 0 - +Rule Kyrgyz 1997 2005 - Mar lastSun 2:30 1:00 S +Rule Kyrgyz 1997 2004 - Oct lastSun 2:30 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Bishkek 4:58:24 - LMT 1924 May 2 5:00 - FRUT 1930 Jun 21 # Frunze Time 6:00 RussiaAsia FRU%sT 1991 Mar 31 2:00s 5:00 1:00 FRUST 1991 Aug 31 2:00 # independence - 5:00 Kirgiz KG%sT # Kirgizstan Time + 5:00 Kyrgyz KG%sT 2005 Aug 12 # Kyrgyzstan Time + 6:00 - KGT ############################################################################### =================================================================== RCS file: RCS/australasia,v retrieving revision 2005.12 retrieving revision 2005.12.0.1 diff -pu -r2005.12 -r2005.12.0.1 --- australasia 2005/08/22 16:05:26 2005.12 +++ australasia 2005/09/25 22:28:01 2005.12.0.1 @@ -1375,16 +1375,26 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901 # mapmakers redrew the IDL following the boundary of Kiribati. Even that line # has a rather arbitrary nature. The straight-line boundaries between Pacific # island nations that are shown on many maps are based on an international -# convention, but are not legally binding national borders. -# -# An Anglo-French Conference on Time-Keeping at Sea (June, 1917) agreed that -# legal time on the high seas would be zone time, i.e., the standard time at -# the nearest meridian that is a multiple of fifteen degrees. The date is +# convention, but are not legally binding national borders.... The date is # governed by the IDL; therefore, even on the high seas, there may be some # places as late as fourteen hours later than UTC. And, since the IDL is not # an international standard, there are some places on the high seas where the # correct date is ambiguous. +# From Wikipedia <http://en.wikipedia.org/wiki/Time_zone> (2005-08-31): +# Before 1920, all ships kept local apparent time on the high seas by setting +# their clocks at night or at the morning sight so that, given the ship's +# speed and direction, it would be 12 o'clock when the Sun crossed the ship's +# meridian (12 o'clock = local apparent noon). During 1917, at the +# Anglo-French Conference on Time-keeping at Sea, it was recommended that all +# ships, both military and civilian, should adopt hourly standard time zones +# on the high seas. Whenever a ship was within the territorial waters of any +# nation it would use that nation's standard time. The captain was permitted +# to change his ship's clocks at a time of his choice following his ship's +# entry into another zone time--he often chose midnight. These zones were +# adopted by all major fleets between 1920 and 1925 but not by many +# independent merchant ships until World War II. + # From Paul Eggert, using references suggested by Oscar van Vlijmen # (2005-03-20): # =================================================================== RCS file: RCS/northamerica,v retrieving revision 2005.13 retrieving revision 2005.13.0.1 diff -pu -r2005.13 -r2005.13.0.1 --- northamerica 2005/08/29 15:54:31 2005.13 +++ northamerica 2005/09/25 22:28:01 2005.13.0.1 @@ -244,6 +244,16 @@ Rule US 2007 max - Nov Sun>=1 2:00 0 S # and didn't change their clocks for Daylight Saving ... so that their # reports will always have times which are 5 hours behind UTC. +# From Paul Eggert (2005-08-26): +# According to today's Huntsville Times +# <http://www.al.com/news/huntsvilletimes/index.ssf?/base/news/112504778322832…> +# a few towns on Alabama's "eastern border with Georgia, such as Phenix City +# in Russell County, Lanett in Chambers County and some towns in Lee County, +# set their watches and clocks on Eastern time." It quotes H.H. "Bubba" +# Roberts, city administrator in Phenix City. as saying "We are in the Central +# time zone, but we do go by the Eastern time zone because so many people work +# in Columbus." + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER Rule NYC 1920 only - Mar lastSun 2:00 1:00 D Rule NYC 1920 only - Oct lastSun 2:00 0 S =================================================================== RCS file: RCS/tz-link.htm,v retrieving revision 2005.13 retrieving revision 2005.13.0.1 diff -pu -r2005.13 -r2005.13.0.1 --- tz-link.htm 2005/08/29 15:54:31 2005.13 +++ tz-link.htm 2005/09/25 22:28:01 2005.13.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-03-11" /> +<meta name="DC.Date" content="2005-09-25" /> <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" /> @@ -52,7 +52,7 @@ title="DJ's GNU Programming Platform">DJ <a href="http://www.sgi.com/developers/technology/irix/">IRIX</a>, <a href="http://www.apple.com/macosx/">Mac OS X</a>, <a href="http://h71000.www7.hp.com/">OpenVMS</a>, -<a href="http://wwws.sun.com/software/solaris/">Solaris</a>, +<a href="http://www.sun.com/software/solaris/">Solaris</a>, <a href="http://h30097.www3.hp.com/">Tru64</a>, and <a href="http://www.sco.com/products/unixware/">UnixWare</a>.</p> <p> @@ -122,7 +122,6 @@ throughout the world.</li> <li><a href="http://www.convertit.com/Go/ConvertIt/World_Time/Current_Time.ASP">Current Time in 1000 Places</a></li> -<li><a href="http://time.world-stay.com/">The time around the world</a></li> <li><a href="http://timezoneconverter.com/">Time Zone Converter</a></li> </ul></li> <li><a href="http://www.timeanddate.com/worldclock/">The World Clock - @@ -180,7 +179,7 @@ available under both the <abbr>GPL</abbr License. DateTime::TimeZone also contains a script <code>tests_from_zdump</code> that generates test cases for each clock transition in the <code>tz</code> database.</li> -<li><a href="http://ibm.com/software/globalization/icu"><abbr +<li><a href="http://www-306.ibm.com/software/globalization/icu/"><abbr title="International Components for Unicode">ICU</abbr></a> contains a C/C++ library for internationalization that has a compiler from <code>tz</code> source @@ -219,7 +218,8 @@ It is freely available under a <abbr>BSD </ul> <h2>Other <code>tz</code>-based time zone software</h2> <ul> -<li><a href="http://freshmeat.net/projects/intclock">International +<li><a +href="http://users.skynet.be/Peter.Verthez/projects/intclock/">International clock (intclock)</a> is a multi-timezone clock for <abbr>GNU</abbr>/Linux and similar systems. It is freely available under the <abbr>GPL</abbr>.</li> @@ -258,10 +258,9 @@ contains data from the Time Service Depa for the <code>usno*</code> files in the <code>tz</code> distribution.</li> <li>The <a href="http://www.iata.org/ps/publications/9179.htm">Standard Schedules Information Manual</a> of the -the <a href="http://www.iata.org/">International Air Transport -Association</a>, -which gives current time zone rules for -all the airports served by commercial aviation.</li> +<a href="http://www.iata.org/index.htm">International Air Transport +Association</a> +gives current time zone rules for airports served by commercial aviation.</li> </ul> <h2>Maps</h2> <ul> @@ -315,6 +314,8 @@ surveys the evolution of timekeeping.</l <li><a href="http://webexhibits.org/daylightsaving/">About Daylight Saving Time - History, rationale, laws & dates</a> is an overall history of <abbr>DST</abbr>.</li> +<li><a href="http://www.energy.ca.gov/daylightsaving.html">Saving Time, +Saving Energy</a> discusses a primary justification for <abbr>DST</abbr>.</li> <li><a href="http://www.seizethedaylight.com/dst/">Who Knew? A Brief History of Daylight Saving Time</a> summarizes some of the contentious history of <abbr>DST</abbr>.</li> @@ -333,11 +334,7 @@ Zone Concepts</a> discusses terminologic <dl> <dt>Australia</dt> <dd>The Bureau of Metrology publishes a list of -<a href="http://www.bom.gov.au/climate/averages/tables/dst_times.shtml">Implementation Dates of Daylight Savings Time within Australia</a>. -The Community Relations Division of the New South Wales -Attorney General's Department maintains a history of <a -href="http://www.lawlink.nsw.gov.au/Lawlink/Corporate/ll_corporate.nsf/pages/atto…">Daylight -Saving in New South Wales</a>.</dd> +<a href="http://www.bom.gov.au/climate/averages/tables/dst_times.shtml">Implementation Dates of Daylight Savings Time within Australia</a>.</dd> <dt>Austria</dt> <dd>The Federal Office of Metrology and Surveying publishes a table of <a href="http://www.metrologie.at/pdf/sommerzeit.pdf" @@ -354,7 +351,7 @@ Portuguese)</a>.</dd> <dt>Canada</dt> <dd>The Institute for National Measurement Standards publishes current and some older information about <a -href="http://inms-ienm.nrc-cnrc.gc.ca/time_services/daylight_savings_e.html">Time +href="http://inms-ienm.nrc-cnrc.gc.ca/en/time_services/daylight_saving_e.php">Time Zones & Daylight Saving Time</a>.</dd> <dt>Chile</dt> <dd>WebExhibits publishes a <a @@ -408,7 +405,7 @@ of Summer time dates</a>.</dd> <h2>Precision timekeeping</h2> <ul> <li><a -href="http://literature.agilent.com/litwebbin/purl.cgi?org_id=tmo&pub_id=5965…">The +href="http://literature.agilent.com/litweb/pdf/5965-7984E.pdf">The Science of Timekeeping</a> is a thorough introduction to the theory and practice of precision timekeeping.</li> <li><a href="http://www.ntp.org/"><abbr @@ -462,13 +459,13 @@ Second Discussion List</a> and <a href="http://rom.usno.navy.mil/archives/leapsecs.html">archive</a> covers <a href="http://gauss.gge.unb.ca/papers.pdf/gpsworld.november99.pdf">McCarthy and Klepczynski's proposal to discontinue leap seconds</a>, published in <a -href="http://www.gpsworld.com/"><abbr +href="http://www.gpsworld.com/gpsworld/"><abbr title="Global Positioning System">GPS</abbr> World</a> <strong>10</strong>, 11 (1999-11), 50–57 and discussed further in R. A. Nelson et al., <a href="http://www.cl.cam.ac.uk/~mgk25/time/metrologia-leapsecond.pdf">The leap second: its history and possible future</a>, -<a href="http://www.bipm.fr/metrologia/">Metrologia</a> +<a href="http://www.bipm.fr/metrologia/index.html">Metrologia</a> <strong>38</strong> (2001), 509–529. <a href="http://www.ucolick.org/~sla/leapsecs/onlinebib.html">The Future of Leap Seconds</a> catalogs information about this @@ -502,7 +499,7 @@ protocols.</li> Best of Dates, the Worst of Dates</a> covers many problems encountered by software developers when handling dates and time stamps.</li> <li><a -href="http://ibm.com/software/globalization/icu"><abbr>ICU</abbr></a> +href="http://www-306.ibm.com/software/globalization/icu/"><abbr>ICU</abbr></a> contains a mechanism for localizing time zone labels and abbreviations; for example, one can use it to specify Russian translations for "Eastern European Summer Time",

1 0

FW: Changing timezone Asia/Bishkek for FreeBSD
by Olson, Arthur David (NIH/NCI) Sept. 22, 2005

Sept. 22, 2005

Malik Abdugaliev is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Malik Abdugaliev [mailto:malik@elcat.kg] Sent: Wednesday, September 21, 2005 2:03 AM To: tz(a)lecserver.nci.nih.gov Subject: Changing timezone Asia/Bishkek for FreeBSD Dear Sirs, I'm one of network administrators of Internet service provider ElCat (http://www.elcat.kg/) We are place in Bishkek, Kyrgyzstan. We use FreeBSD 4.10 and 5.4 and we need to update time zone file for our country. Our government cancels daylight saving time 6th of August 2005. >From August 12 2005 our GMT-offset is +6, w/o any daylight saving. Please check my changes for zone Asia/Bishkek and rule Kirgiz in file /usr/src/share/zoneinfo/asia is correct and make the changes for use in the future: #--- cut here # Kyrgyzstan (Kirgizstan) # Transitions through 1991 are from Shanks. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/ Rule Kirgiz 1992 1996 - Apr Sun>=7 0:00s 1:00 S Rule Kirgiz 1992 1996 - Sep lastSun 0:00 0 - Rule Kirgiz 1997 2005 - Mar lastSun 2:30 1:00 S Rule Kirgiz 1997 2004 - Oct lastSun 2:30 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Bishkek 4:58:24 - LMT 1924 May 2 5:00 - FRUT 1930 Jun 21 # Frunze Time 6:00 RussiaAsia FRU%sT 1991 Mar 31 2:00s 5:00 1:00 FRUST 1991 Aug 31 2:00 # independence 5:00 Kirgiz KG%sT 2005 Aug 12 # Kirgizstan Time 6:00 - KGT # Kyrgyzstan Time #--- cut here Unfortunately I didn't find any official documents published in Internet in English. Thank you much. Malik Abdugaliev. # Network Administrator # ElCat, Bishkek, Kyrgyzstan # ZED-RIPE # http://www.elcat.kg/

1 0

Changing timezone Asia/Bishkek for FreeBSD
by Malik Abdugaliev Sept. 21, 2005

Sept. 21, 2005

Dear Sirs, I'm one of network administrators of Internet service provider ElCat (http://www.elcat.kg/) We are place in Bishkek, Kyrgyzstan. We use FreeBSD 4.10 and 5.4 and we need to update time zone file for our country. Our government cancels daylight saving time 6th of August 2005. >From August 12 2005 our GMT-offset is +6, w/o any daylight saving. Please check my changes for zone Asia/Bishkek and rule Kirgiz in file /usr/src/share/zoneinfo/asia is correct and make the changes for use in the future: #--- cut here # Kyrgyzstan (Kirgizstan) # Transitions through 1991 are from Shanks. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/ Rule Kirgiz 1992 1996 - Apr Sun>=7 0:00s 1:00 S Rule Kirgiz 1992 1996 - Sep lastSun 0:00 0 - Rule Kirgiz 1997 2005 - Mar lastSun 2:30 1:00 S Rule Kirgiz 1997 2004 - Oct lastSun 2:30 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Bishkek 4:58:24 - LMT 1924 May 2 5:00 - FRUT 1930 Jun 21 # Frunze Time 6:00 RussiaAsia FRU%sT 1991 Mar 31 2:00s 5:00 1:00 FRUST 1991 Aug 31 2:00 # independence 5:00 Kirgiz KG%sT 2005 Aug 12 # Kirgizstan Time 6:00 - KGT # Kyrgyzstan Time #--- cut here Unfortunately I didn't find any official documents published in Internet in English. Thank you much. Malik Abdugaliev. # Network Administrator # ElCat, Bishkek, Kyrgyzstan # ZED-RIPE # http://www.elcat.kg/

1 0