- tz - lists.iana.org

FW: [casting; overflow detection]
by Olson, Arthur David (NIH/NCI) [E] Feb. 14, 2011

Feb. 14, 2011

I'm forwarding this message from Christos Zoulas. --ado -----Original Message----- From: Christos Zoulas [mailto:christos@zoulas.com] Sent: Thursday, January 13, 2011 8:50 To: Olson, Arthur David (NIH/NCI) [E] Subject: Hi, Mail to the tz mailing list does not seem to go through from my server. E82CA564C4 2128 Thu Jan 13 04:00:52 christos(a)zoulas.com (connect to lecserver.nci.nih.gov[137.187.215.78]: Operation timed out) tz(a)lecserver.nci.nih.gov I I sent the following two messages: Best, christos >From christos Wed Jan 12 11:49:47 2011 From: christos(a)rebar.astron.com (Christos Zoulas) Date: Wed, 12 Jan 2011 11:49:47 -0500 In-Reply-To: <201101121624.p0CGOrGD018457(a)lecserver.nci.nih.gov> from Arthur David Olson (Jan 12, 11:24am) Organization: Astron Software X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: <tz(a)elsie.nci.nih.gov>, <tz(a)lecserver.nci.nih.gov> Subject: Re: proposed time zone package changes (Hawaii, stack overflow, et al.) Status: OR On Jan 12, 11:24am, olsona(a)elsie.nci.nih.gov (Arthur David Olson) wrote: -- Subject: proposed time zone package changes (Hawaii, stack overflow, et al | If no problems are found, these changes will appear in tzcode2011a.tar.gz | and tzdata2011.tar.gz on 2011-11-23. Please don't cast the result of calloc(3). It will hide errors where the prototype is not in scope and then the function is assumed to return "int" which breaks on 64 bit systems. It's been more than 20 years (22 actually since c89) since ANSI C made allocation functions return "void *" :-) On a different subject, I've committed the reentrant versions of the timezone code to the NetBSD tree. Is there any chance that those changes will be merged anytime soon? Or do people need more time to review them? How do we go about accepting or rejecting them? Should there be a vote? Best, christos >From christos Wed Jan 12 23:00:52 2011 From: christos(a)rebar.astron.com (Christos Zoulas) Date: Wed, 12 Jan 2011 23:00:52 -0500 Organization: Astron Software X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: tz(a)lecserver.nci.nih.gov Subject: Gcc and integer overflow Status: OR Hello, Integer overflow in ansi c has undefined behavior. Gcc 4.5.x takes advantage of this fact to optimize code. In particular you cannot depend anymore on: int oldx = x; x += delta; if ((oldx > x && delta > 0) || (oldx < x && delta < 0)) overflow; What happens in fact, is that gcc will warn, and drop the code that is "impossible" (drop the whole if statement). Unfortunately tzcode relies on the above behavior to detect overflow. I have changed the code the following way (but I have not tested it), so if you please can you check my work, or propose a better way to do it. I think we should come up with a viable solution for the next tzcode release. Many thanks, christos Index: localtime.c =================================================================== RCS file: /cvsroot/src/lib/libc/time/localtime.c,v retrieving revision 1.51 diff -u -u -r1.51 localtime.c --- localtime.c 6 Jan 2011 02:41:34 -0000 1.51 +++ localtime.c 10 Jan 2011 21:32:09 -0000 @@ -1703,9 +1703,16 @@ { int number0; + if (delta == 0) + return 0; + number0 = *number; *number += delta; - return (*number < number0) != (delta < 0); + + if (delta < 0) + return number0 < 0 && (-*number + INT_MIN) > delta; + else /* delta > 0 */ + return number0 > 0 && (INT_MAX - *number) < delta; } static int @@ -1713,9 +1720,16 @@ { long number0; + if (delta == 0) + return 0; + number0 = *number; *number += delta; - return (*number < number0) != (delta < 0); + + if (delta < 0) + return number0 < 0 && (-*number + LONG_MIN) > delta; + else /* delta > 0 */ + return number0 > 0 && (LONG_MAX - *number) < delta; } static int

5 8

Fwd: Question about time period transition points
by Mike Giroux Feb. 14, 2011

Feb. 14, 2011

Wise ones of the TZ list, A (quite academic, but possibly interesting) question came up here as we're trying to document the behaviour of our time zone code. We're trying to figure out whether the transition time is reached or skipped. For example, for these 2 rules, # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule TC 1979 1986 - Apr lastSun 2:00 1:00 D Rule TC 1979 2006 - Oct lastSun 2:00 0 S does the clock reach "2:00" on the transition days? In that case, the transition would go from "2:00(S)" -> "3:00(D) + epsilon" when moving forward, and "2:00(D)" -> "1:00(S) + epsilon" when moving back. Or does it go from "2:00(S) - epsilon" -> "3:00(D)" and "2:00(D) - epsilon" -> "1:00(S)" ? If the transition time IS reached, which "name" would attach to it? Phrased differently, for the Americas/NewYork transitions this spring: 1) Is the time coordinate value at the instant of transition "2:00 AM" or "3:00 AM" (NIST says "begins at 2:00 a.m. on the second Sunday of March") 2) Is the designation of that coordinate (in the local New York City timezone) "EDT" or "EST"? Thanks! Mike

3 6

RE: New site with North American Time Zone borders
by Steve Jones Feb. 11, 2011

Feb. 11, 2011

At 11:45 2/11/2011, Chris Walton wrote: >Back in 2007 I posted a Canadian time zone map >in one of the Google Earth forums. Chris: Very nice! My implementation of the kml version is much less ambitious, but I hope to keep it at least accurate. I'm very grateful for the feedback on my errors and I will roll it into my next release. I've also mimicked your shape for the east Kootenays for my next release. Are you certain that the border from just north of Riondel to Glacier NP lies to the east of the lake road? I had it running through the lake and then up the Duncan river from there. I can't recall where I got that. I also had the border of the no-DST area of BC near Dawson Creek drawn a bit too far north. That line bisects Hwy 97 twice, once between Chetwynd and McLeod Lake, and again just south of Sikanni. I wish I knew the precise coordinates of those two transitions. Do you happen to have that? >I guess we should assume that Petit-Mécatina is >now on AST year round as you have indicated. Interesting that the Quebec/Labrador border between Blanc-Sablon and L'anse-au-Clair is apparently a 90 minute transition in the summer time when it separates Atlantic Standard from Newfoundland Daylight. I can't recall running into any other instances of a border transition being over 60 minutes. It must be very confusing keeping the ferry departure/arrival times straight for the St. Barbe / Blanc Sablon ferry. Thanks again. Cheers, Steve Jones OnTimeZone.com

2 1

RE: New site with North American Time Zone borders
by Steve Jones Feb. 11, 2011

Feb. 11, 2011

Chris: A couple of follow up questions: In http://www.canadiangeographic.ca/Magazine/SO98/alacarte.asp it says that all of Baffin Island observes Eastern Time. I'm pretty sure that Arctic Bay does, and it is situated (barely) west of the 85° line. I think that may be the westernmost settlement on the island. So that leaves a discrepancy between our maps. Do you have any insights on this? We also have discrepancies for Sturgeon Landing (south of Denare Beach) and Paynton (East of Lloydminster) on opposite sides of Saskatchewan. Looking back to my sources, they are not definitive. I presume I should adjust my borders. Cheers, Steve Jones OnTimeZone.com

1 0

FW: C/C++ library that parses TZ data?
by Olson, Arthur David (NIH/NCI) [E] Feb. 10, 2011

Feb. 10, 2011

I'm forwarding this message from Dario Teixeira, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado -----Original Message----- From: Dario Teixeira [mailto:darioteixeira@yahoo.com] Sent: Wednesday, February 09, 2011 11:03 To: tz(a)lecserver.nci.nih.gov Subject: C/C++ library that parses TZ data? Hi, I have a problem which is fairly common when one is running a web application that wishes to display timestamps localised towards each user's time zone. Basically, I need a function that takes as input a timestamp in UTC and a time zone specified in the Zoneinfo convention (ex: "Europe/Lisbon"), and returns the localised version of that timestamp, including a time zone abbreviation aware of daylight savings. Example: 2010-01-01 15:30, "Europe/Lisbon" -> 2010-01-01 15:30 WET 2010-01-01 15:30, "Europe/Paris" -> 2010-01-01 16:30 CET 2010-07-01 15:30, "Europe/Lisbon" -> 2010-07-01 16:30 WEST 2010-07-01 15:30, "Europe/Paris" -> 2010-07-01 17:30 CEST Since the zoneinfo data is present in every Unix system and glibc includes routines for parsing it, interfacing with glibc seemed the obvious solution. Unfortunately, glibc was not designed with this use case in mind. In fact, the glibc interface to zoneinfo can be described as "sui generis" if one is feeling charitable, or "insane" if truth must be told. Specifically, to obtain the localised version of a given timestamp, one must first set the 'TZ' environment variable with the target timezone, and then invoke 'localtime'. The abbreviated name of the timezone can be found in the global 'tzname' array: at position 'tzname[0]' if daylight savings are not in effect and at position 'tzname[1]' if they are. A quick search through glibc's bugzilla shows I'm not the only one to find this interface anachronistic [1], but it also reveals that it is unlikely to change. So, my question is if someone is aware of some alternative library in C or C++ that provides this same functionality, but is friendlier towards concurrent applications. Best regards, Dario Teixeira [1] http://sources.redhat.com/bugzilla/show_bug.cgi?id=11620

6 7

Russia to turn clocks forward, but not back again in 2011
by Steffen Thorsen Feb. 9, 2011

Feb. 9, 2011

Many news sources report that Russia will move clocks forward for DST as usual, but not back again, so they will stay permanently on DST, from 2011. Some examples: http://themoscownews.com/society/20110208/188402634.html http://www.straitstimes.com/BreakingNews/World/Story/STIStory_632614.html We will keep this page updated: http://www.timeanddate.com/news/time/russia-winter-time.html Best regards, Steffen Thorsen - timeanddate.com

2 1

Metlakatla
by Olson, Arthur David (NIH/NCI) [E] Feb. 9, 2011

Feb. 9, 2011

I just spoke by phone with a staff member at the Metlakatla Indian Community office (using contact information available at http://www.commerce.state.ak.us/dca/commdb/CIS.cfm?Comm_Boro_name=Metlakatla) It's shortly after 1:00 p.m. here on the east coast of the United States; the staffer said it was shortly after 10:00 there. When I asked whether that meant they were on Pacific time, they said no--they were on their own time. I asked about daylight saving; they said it wasn't used. I did not inquire about practices in the past. --ado

1 0

C/C++ library that parses TZ data?
by Dario Teixeira Feb. 9, 2011

Feb. 9, 2011

Hi, I have a problem which is fairly common when one is running a web application that wishes to display timestamps localised towards each user's time zone. Basically, I need a function that takes as input a timestamp in UTC and a time zone specified in the Zoneinfo convention (ex: "Europe/Lisbon"), and returns the localised version of that timestamp, including a time zone abbreviation aware of daylight savings. Example: 2010-01-01 15:30, "Europe/Lisbon" -> 2010-01-01 15:30 WET 2010-01-01 15:30, "Europe/Paris" -> 2010-01-01 16:30 CET 2010-07-01 15:30, "Europe/Lisbon" -> 2010-07-01 16:30 WEST 2010-07-01 15:30, "Europe/Paris" -> 2010-07-01 17:30 CEST Since the zoneinfo data is present in every Unix system and glibc includes routines for parsing it, interfacing with glibc seemed the obvious solution. Unfortunately, glibc was not designed with this use case in mind. In fact, the glibc interface to zoneinfo can be described as "sui generis" if one is feeling charitable, or "insane" if truth must be told. Specifically, to obtain the localised version of a given timestamp, one must first set the 'TZ' environment variable with the target timezone, and then invoke 'localtime'. The abbreviated name of the timezone can be found in the global 'tzname' array: at position 'tzname[0]' if daylight savings are not in effect and at position 'tzname[1]' if they are. A quick search through glibc's bugzilla shows I'm not the only one to find this interface anachronistic [1], but it also reveals that it is unlikely to change. So, my question is if someone is aware of some alternative library in C or C++ that provides this same functionality, but is friendlier towards concurrent applications. Best regards, Dario Teixeira [1] http://sources.redhat.com/bugzilla/show_bug.cgi?id=11620

1 0

2011a
by Olson, Arthur David (NIH/NCI) [E] Feb. 8, 2011

Feb. 8, 2011

The files... ftp://elsie.nci.nih.gov/pub/tzcode2011a.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2011a.tar.gz ...are now available; these reflect the changes circulated in the last two weeks on the time zone mailing list. --ado

3 5

lat/lon to time offset database
by Larry Ober Feb. 7, 2011

Feb. 7, 2011

I'm a nubie at understanding the ins and outs of timezones so please forgive me for my potentially dumb questions. I am looking at building a small embedded system (No OS) that will require determining the local time from the lat/lon of a location. So basically I need lat/lon to time offset from "GMT". I don't really need the geo political information like country or city. However it seems like tz is structured continent/country/city/... Now maybe I already have what I need but I just don't understand it. I have a copy of timezone.csv that seems to include data from country code to city etc. This seems to point to what looks like coordinate data that I don't understand. An example for America/New York seems to point to an area 115. There then seem to be multiple 115 entries like the following; 115, 3907893600, -18000, EST, 0 115, 3919388400, -14400, EDT, 1 My interpretation is that 115 is the area, the next column should be some sort of latitude, next seems to be called an offset in other contexts, next is the used name of the zone followed by a true/false bit. If this is basically true, I guess that what I don't understand it how to "parse" the latitude and how to use the longitude offset. Of course maybe I have this entirely wrong. I would appreciate any help on this basic issue. Regards Larry

28 46

2011b
by Olson, Arthur David (NIH/NCI) [E] Feb. 7, 2011

Feb. 7, 2011

The files... ftp://elsie.nci.nih.gov/pub/tzcode2011b.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2011b.tar.gz ...are now available; these reflect the changes circulated recently on the time zone mailing list. I plan to try contacting someone on Annette Island on Wednesday regarding time there. --ado

2 1

FW: "Etc\GMT" positive and negative
by Olson, Arthur David (NIH/NCI) [E] Feb. 4, 2011

Feb. 4, 2011

-----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] Sent: Tuesday, February 01, 2011 12:26 To: 'tz(a)elsie.nci.nh.gov' Cc: 'Exis.rdiaz(a)iberia.es' Subject: FW: "Etc\GMT" positive and negative I'm forwarding this message from Rodrigo Díaz López, who is not on the time one mailing list. Those of you who are on the list, please direct replies appropriately. --ado From: EXIS.Diaz Lopez, Rodrigo [mailto:EXIS.rdiaz@iberia.es] Sent: Tuesday, February 01, 2011 12:25 To: tz(a)elsie.nci.nih.gov Subject: "Etc\GMT" positive and negative Hi: I think I found a bug with the "Etc\GMT" zones. If you use a "positive zone" like Etc\GMT+2 for calculate actual local time in this zone you obtain. local time for Etc\GMT-2 (¡a negative zone!). For instance, its' 5:00 PM (UTC/GMT), so in GMT+2 zone (Greece) the local time must be 7:00 PM. But, if you use TZ Database, you obtain. ¡3:00 PM! And the opposite for "negative zones". Is a bit funny. Please, check it. I found a web page (http://www.gsp.com/support/virtual/admin/unix/tz/gmt/) that use tz database (I think) and shows this error. Best regards. P.S.: It is possible that the problem was with the "codes", because in the world there are "GMT+13" and "GMT+14" zones, and these zones do not exist in tz database. However, in tz database exists "GMT-13" and "GMT-14" zones, that not exist in the real world. -- Rodrigo Díaz López EXIS.rdiaz(a)iberia.es IBERIA.com Tu viaje de principio a fin IBERIA.com Your journey from start to finish

4 3

Bulletin C number 41
by IERS EOP Product Center Feb. 2, 2011

Feb. 2, 2011

INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : 33 (0) 1 40 51 22 29 FAX : 33 (0) 1 40 51 22 91 Internet : services.iers(a)obspm.fr Paris, 2 February 2011 Bulletin C 41 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO positive leap second will be introduced at the end of June 2011. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2009 January 1, 0h UTC, until further notice : UTC-TAI = -34 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Daniel GAMBIS Head Earth Orientation Center of the IERS Observatoire de Paris, France __________________________________________

1 0

FW: [Meticulous] and well researched article on Alaska time zones
by Olson, Arthur David (NIH/NCI) [E] Feb. 1, 2011

Feb. 1, 2011

I'm forwarding this message from Steve Ferguson, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado From: Steve Ferguson [mailto:s_t_e_v_e_f@yahoo.com] Sent: Monday, January 31, 2011 1:50 To: tz(a)lecserver.nci.nih.gov Subject: [Meticulous] and well researched article on Alaska time zones The author lives in Alaska and many of the references listed are only available to Alaskan residents. http://www.alaskahistoricalsociety.org/index.cfm?section=discover%20alaska&…

4 5

"Etc\GMT" positive and negative
by EXIS.Diaz Lopez, Rodrigo Feb. 1, 2011

Feb. 1, 2011

Hi: I think I found a bug with the "Etc\GMT" zones. If you use a "positive zone" like Etc\GMT+2 for calculate actual local time in this zone you obtain... local time for Etc\GMT-2 (¡a negative zone!). For instance, its' 5:00 PM (UTC/GMT), so in GMT+2 zone (Greece) the local time must be 7:00 PM. But, if you use TZ Database, you obtain... ¡3:00 PM! And the opposite for "negative zones". Is a bit funny. Please, check it. I found a web page (http://www.gsp.com/support/virtual/admin/unix/tz/gmt/) that use tz database (I think) and shows this error. Best regards. P.S.: It is possible that the problem was with the "codes", because in the world there are "GMT+13" and "GMT+14" zones, and these zones do not exist in tz database. However, in tz database exists "GMT-13" and "GMT-14" zones, that not exist in the real world. -- Rodrigo Díaz López EXIS.rdiaz(a)iberia.es<mailto:EXIS.rdiaz@iberia.es> IBERIA.com<http://www.iberia.com> Tu viaje de principio a fin IBERIA.com<http://www.iberia.com/?language=en> Your journey from start to finish

1 0

Maticulous and well researched article on Alaska time zones
by Steve Ferguson Jan. 30, 2011

Jan. 30, 2011

The author lives in Alaska and many of the references listed are only available to Alaskan residents. http://www.alaskahistoricalsociety.org/index.cfm?section=discover%20alaska&…

1 0

proposed time zone package changes (Mercer ND, Indonesian names, date.c overflow-proofing)
by Arthur David Olson Jan. 26, 2011

Jan. 26, 2011

Here are proposed changes to the time zone package; the executive summary: * date.c Replace "comptm" with "sametm" to avoid potential overflow (with code simplification as a side effect). * northamerica Add America/North_Dakota/Beulah (Mercer County, North Dakota, moved from Mountain to Central time at end of DST in 2010); use actual version number rather than "%W%". * zone.tab Add America/North_Dakota/Beulah (Mercer County, North Dakota, moved from Mountain to Central time at end of DST in 2010); update Indonesian location names (with old names retained in parentheses). The update to "northamerica" does affect current time stamps. There's more overflow work to do; the date.c work above is just the low-hanging fruit. For Indonesian locations I referred to... https://www.cia.gov/library/publications/the-world-factbook/graphics/ref_ma… ...and... https://www.cia.gov/library/publications/the-world-factbook/graphics/ref_ma… ...but note that the island labeled "Sulawesi (Celebes)" in "asia.pdf" is labeled "Celebes" in "oceania.pdf". (This paragraph may serves to notify the CIA of the problem:-) Also, the map at... http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=maluku&aq=&sll=… ...shows islands labeled "Maluku" and "Maluku Utara" and a sea labeled "Molucca Sea." If no problems are found, I'll update the ftp site on 2011-02-07. --ado diff -r -c old/date.c new/date.c *** old/date.c Thu Dec 16 12:24:43 2010 --- new/date.c Tue Jan 25 16:12:48 2011 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)date.c 8.4"; /* ** Modified from the UCB version with the SCCS ID appearing below. */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)date.c 8.5"; /* ** Modified from the UCB version with the SCCS ID appearing below. */ *************** *** 76,82 **** static int retval = EXIT_SUCCESS; static void checkfinal(const char *, int, time_t, time_t); - static int comptm(const struct tm *, const struct tm *); static time_t convert(const char *, int, time_t); static void display(const char *); static void dogmt(void); --- 76,81 ---- *************** *** 86,91 **** --- 85,91 ---- static const char * nondigit(const char *); static void oops(const char *); static void reset(time_t, int); + static int sametm(const struct tm *, const struct tm *); static void timeout(FILE *, const char *, const struct tm *); static void usage(void); static void wildinput(const char *, const char *, *************** *** 594,612 **** } static int ! comptm(atmp, btmp) register const struct tm * const atmp; register const struct tm * const btmp; { ! register int result; ! ! if ((result = (atmp->tm_year - btmp->tm_year)) == 0 && ! (result = (atmp->tm_mon - btmp->tm_mon)) == 0 && ! (result = (atmp->tm_mday - btmp->tm_mday)) == 0 && ! (result = (atmp->tm_hour - btmp->tm_hour)) == 0 && ! (result = (atmp->tm_min - btmp->tm_min)) == 0) ! result = atmp->tm_sec - btmp->tm_sec; ! return result; } /* --- 594,609 ---- } static int ! sametm(atmp, btmp) register const struct tm * const atmp; register const struct tm * const btmp; { ! return atmp->tm_year == btmp->tm_year && ! atmp->tm_mon == btmp->tm_mon && ! atmp->tm_mday == btmp->tm_mday && ! atmp->tm_hour == btmp->tm_hour && ! atmp->tm_min == btmp->tm_min && ! atmp->tm_sec == btmp->tm_sec; } /* *************** *** 708,714 **** tm.tm_isdst = -1; outtm = tm; outt = mktime(&outtm); ! return (comptm(&tm, &outtm) == 0) ? outt : -1; } /* --- 705,711 ---- tm.tm_isdst = -1; outtm = tm; outt = mktime(&outtm); ! return sametm(&tm, &outtm) ? outt : -1; } /* *************** *** 746,752 **** othertm.tm_isdst = !tm.tm_isdst; othert = mktime(&othertm); if (othert != -1 && othertm.tm_isdst != tm.tm_isdst && ! comptm(&tm, &othertm) == 0) iffy(t, othert, value, _("both standard and summer time versions exist")); /* --- 743,749 ---- othertm.tm_isdst = !tm.tm_isdst; othert = mktime(&othertm); if (othert != -1 && othertm.tm_isdst != tm.tm_isdst && ! sametm(&tm, &othertm)) iffy(t, othert, value, _("both standard and summer time versions exist")); /* *************** *** 776,782 **** othert = t + 60 * offset; else othert = t - 60 * offset; othertm = *localtime(&othert); ! if (comptm(&tm, &othertm) == 0) iffy(t, othert, value, _("multiple matching times exist")); } --- 773,779 ---- othert = t + 60 * offset; else othert = t - 60 * offset; othertm = *localtime(&othert); ! if (sametm(&tm, &othertm)) iffy(t, othert, value, _("multiple matching times exist")); } diff -r -c old/northamerica new/northamerica *** old/northamerica Thu Jan 20 07:14:48 2011 --- new/northamerica Wed Jan 26 17:13:48 2011 *************** *** 1,5 **** # <pre> ! # %W% # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)northamerica 8.40 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 346,351 **** --- 346,372 ---- -7:00 US M%sT 2003 Oct 26 02:00 -6:00 US C%sT + # From Josh Findley (2011-01-21): + # ...it appears that Mercer County, North Dakota, changed from the + # mountain time zone to the central time zone at the last transition from + # daylight-saving to standard time (on Nov. 7, 2010): + # <a href="http://www.gpo.gov/fdsys/pkg/FR-2010-09-29/html/2010-24376.htm"> + # http://www.gpo.gov/fdsys/pkg/FR-2010-09-29/html/2010-24376.htm + # </a> + # <a href="http://www.bismarcktribune.com/news/local/article_1eb1b588-c758-11df-b472-0…"> + # http://www.bismarcktribune.com/news/local/article_1eb1b588-c758-11df-b472-0… + # </a> + + # From Andy Lipscomb (2011-01-24): + # ...according to the Census Bureau, the largest city is Beulah (although + # it's commonly referred to as Beulah-Hazen, with Hazen being the next + # largest city in Mercer County). Google Maps places Beulah's city hall + # at 4715'51" north, 10146'40" west, which yields an offset of 6h47'07". + + Zone America/North_Dakota/Beulah -6:47:07 - LMT 1883 Nov 18 12:12:53 + -7:00 US M%sT 2010 Nov 7 2:00 + -6:00 US C%sT + # US mountain time, represented by Denver # # Colorado, far western Kansas, Montana, western diff -r -c old/zone.tab new/zone.tab *** old/zone.tab Thu Dec 16 12:24:20 2010 --- new/zone.tab Wed Jan 26 18:47:09 2011 *************** *** 1,5 **** # <pre> ! # @(#)zone.tab 8.38 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. # --- 1,5 ---- # <pre> ! # @(#)zone.tab 8.40 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. # *************** *** 211,218 **** HU +4730+01905 Europe/Budapest ID -0610+10648 Asia/Jakarta Java & Sumatra ID -0002+10920 Asia/Pontianak west & central Borneo ! ID -0507+11924 Asia/Makassar east & south Borneo, Celebes, Bali, Nusa Tengarra, west Timor ! ID -0232+14042 Asia/Jayapura Irian Jaya & the Moluccas IE +5320-00615 Europe/Dublin IL +3146+03514 Asia/Jerusalem IM +5409-00428 Europe/Isle_of_Man --- 211,218 ---- HU +4730+01905 Europe/Budapest ID -0610+10648 Asia/Jakarta Java & Sumatra ID -0002+10920 Asia/Pontianak west & central Borneo ! ID -0507+11924 Asia/Makassar east & south Borneo, Sulawesi (Celebes), Bali, Nusa Tengarra, west Timor ! ID -0232+14042 Asia/Jayapura west New Guinea (Irian Jaya) & Malukus (Moluccas) IE +5320-00615 Europe/Dublin IL +3146+03514 Asia/Jerusalem IM +5409-00428 Europe/Isle_of_Man *************** *** 404,409 **** --- 404,410 ---- US +450628-0873651 America/Menominee Central Time - Michigan - Dickinson, Gogebic, Iron & Menominee Counties US +470659-1011757 America/North_Dakota/Center Central Time - North Dakota - Oliver County US +465042-1012439 America/North_Dakota/New_Salem Central Time - North Dakota - Morton County (except Mandan area) + US +471551-1014640 America/North_Dakota/Beulah Central Time - North Dakota - Mercer County US +394421-1045903 America/Denver Mountain Time US +433649-1161209 America/Boise Mountain Time - south Idaho & east Oregon US +364708-1084111 America/Shiprock Mountain Time - Navajo

1 0

FW: Mercer County, N. D.
by Olson, Arthur David (NIH/NCI) [E] Jan. 24, 2011

Jan. 24, 2011

I'm forwarding this message from Josh Findley, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado -----Original Message----- From: Josh Findley [mailto:tz.4.jfindley@spamgourmet.com] Sent: Friday, January 21, 2011 6:05 To: tz(a)lecserver.nci.nih.gov Subject: Mercer County, N. D. In case you are not aware already, it appears that Mercer County, North Dakota, changed from the mountain time zone to the central time zone at the last transition from daylight-saving to standard time (on Nov. 7, 2010): http://www.gpo.gov/fdsys/pkg/FR-2010-09-29/html/2010-24376.htm http://www.bismarcktribune.com/news/local/article_1eb1b588-c758-11df-b472-0… Josh Findley

2 1

FW: Archaic terms for Indonesian island groups
by Olson, Arthur David (NIH/NCI) [E] Jan. 24, 2011

Jan. 24, 2011

I'm forwarding this message from Alexander Ray, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado From: alexander.ray(a)internode.on.net [mailto:alexander.ray@internode.on.net] Sent: Saturday, January 22, 2011 2:20 To: tz(a)lecserver.nci.nih.gov Subject: Archaic terms for Indonesian island groups A Wikipedia user has brought it to my attention that some of the terms for Indonesian islands used in the database are incorrect, archaic forms. The listings should be as follows. ID -0610+10648 Asia/Jakarta Java & Sumatra ID -0002+10920 Asia/Pontianak west & central Borneo ! ID -0507+11924 Asia/Makassar east & south Borneo, Sulawesi, Bali, Nusa Tenggara, west Timor ! ID -0232+14042 Asia/Jayapura western New Guinea, Maluku islands

1 0

A suggestion for improving the accuracy of LMT of Asia/Tokyo
by Fumiyuki Shimizu Jan. 23, 2011

Jan. 23, 2011

To whom it may concern, First of all, I'd like to express my appreciation for your maintaining the time zone database over the world. With regards to the current LMT of Asia/Tokyo, there are two problems. 1. It is based on 'Tokyo Datum' using Bessel ellipsoid of which equatorial radius, and flattening are less accurate than GRS80. 2. Location of origin point used by 'Rika Nenpyou (until 2009)' was not commonly used for geodetic reference system in Japan. To fix problem #1, which is illustrated in detail below as (Zt) and (Zj), E 139 44' 40.90" (9h 18m 58.7266s) should be E 139 44' 29.27" (9h 18m 57.9513s) To fix problem #2, which is illustrated in detail below as (Zj) and (Xj), E 139 44' 29.27" (9h 18m 57.9513s) should be E 139 44' 28.8759" (9h 18m 57.9250s) The influence of problem #2 is insignificant, but problem #1 causes a one-second difference. Therefore, though the priority of pursuing accuracy of LMT may be low, I believe that there is not much reason in continuing to use the current value, and the line should be updated as: --- tzdata2010o/asia 2010-11-01 22:18:22.000000000 +0900 +++ tzdata/asia 2011-01-10 13:25:42.000000000 +0900 @@ -1280,7 +1280,7 @@ # ordinances took effect on Jan 1. # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Asia/Tokyo 9:18:59 - LMT 1887 Dec 31 15:00u +Zone Asia/Tokyo 9:18:58 - LMT 1887 Dec 31 15:00u 9:00 - JST 1896 9:00 - CJT 1938 9:00 Japan J%sT --------------- The reasons are as follows: * Geodetic reference system in Japan[*1][*2JA]: 1918(?)-2002/3/31: Tokyo Datum(Bessel) 2002/4/1- : Japanese Geodetic Datum 2000 - JGD2000(ITRF94,GRS80) * Location of origin point(normally used for geodetic reference system in Japan)[*1 4.4.2][*8JA]: (X')1892-1923/9/1 "The center point of the Merz-Repsold meridian circle of the former Tokyo Astronomical Observatory, Azabudai 2-18-1, Minato-ku, Tokyo" (X)1923/?/?- "The intersection point of the cross carved on the metal mark of Nihon Keiido Genten, Azabudai 2-18-1, Minato-ku, Tokyo" * The base point of "Tokyo" in Rika Nenpyou[*5JA][*6JA][*7JA][*8JA]: (Z)1925-2009 "The site of the center point of the Repsold transit instrument of the former Tokyo Astronomical Observatory, Azabudai 2-18-1, Minato-ku, Tokyo" (Z) was located at 10meter east of (X')[*4JA]. 2010- They changed the point to same as (X). ** Those points in Tokyo Datum(Bessel) (Xt): E 139 44' 40.5020" N 35 39' 17.5148" [*5JA] => 9h 18m 58.7001s (Zt): E 139 44' 40.90" N 35 39' 16"(*) [*5JA] => 9h 18m 58.7266s (Zt) is the value taken currently by the TZ database(2010o). (*) Since longitude and latitude of (Zt) are based on the different measurements[*5JA], and (Z) was located at 10meter east of (X')[*4JA], (Zt) should be about E 139 44' 40.90" N 35 39' 17.51". The value of (Zt) above is not normal value, but its effect on the symptom is slight, since the difference is in the latitude. ** Those points in JGD2000(=~ WGS84) (Xj): E 139 44' 28.8759" N 35 39' 29.1572" [*10][*11][*3JA][*5JA][*6JA][*7JA] => 9h 18m 57.9250s (Zj): E 139 44' 29.27" N 35 39' 27.7" [*5JA] => 9h 18m 57.9513s Additional Note: Solar longitude: As for solar longitude, threre is data that Akashi Municipal Planetarium is located on E 135(9h) in solar longitude[*9JA]. E 135 in "Tokyo Datum" is 370meter west of the planetarium[*9JA]. E 135 in "WGS" is 120meter west of the planetarium[*9JA]. 120meter east-west is about 4.712"(0.314s) in WGS longitude at the point. 9h 18m 57.9250s(Xj) + 0.314s = 9h 18m 58.24s "9:18:58" seems to work even concerning for the solar longitude, although 0.314s is not a value at (X). - References Geospatial Information Authority of Japan http://www.gsi.go.jp/ENGLISH/index.html National Astronomical Observatory of Japan http://www.nao.ac.jp/E/index.html [*1] Concept of the New Japanese Geodetic System http://www.gsi.go.jp/common/000001195.pdf [*2JA] http://www.gsi.go.jp/LAW/G2000-g2000faq-1.htm (in Japanese) [*3JA] Nihon Keiido Genten (Origin point of Japanese Geodetic System) http://www.gsi.go.jp/kanto/ki8cgenten.html (in Japanese) [*4JA] http://www.gsi.go.jp/kohokocho/kohokocho40182.html (in Japanese) [*5JA] Rika Nenpyou (Chronological Scientific Table) 2010 p.Koyomi76(76) 2009/11/26 National Astronomical Observatory of Japan http://www.rikanenpyo.jp/ (in Japanese) [*6JA] Rika Nenpyou (Chronological Scientific Table) 2010 p.4 [*7JA] Rika Nenpyou (Chronological Scientific Table) 2011 p.4 2010/11/26 National Astronomical Observatory of Japan [*8JA] http://www.gsi.go.jp/kohokocho/koho507-2.html (in Japanese) [*9JA] Akashi Municipal Planetarium http://www.am12.jp/faq/shigosen.html (in Japanese) [*10] Realization of Horizontal Geodetic Coordinates 2000 2.3.3 http://www.gsi.go.jp/common/000001196.pdf [*11] RealizationGeographical Survey Institute Japan 2005 p.10 http://www.gsi.go.jp/ENGLISH/ABOUT/REPORT/Annual_2005.pdf - --- I hope this information helps. Thank you and best regards, --- Fumiyuki Shimizu 清水文行 fumifumi(a)abacustech.jp Abacus Technologies, Inc.

3 2

Archaic terms for Indonesian island groups
by alexander.ray＠internode.on.net Jan. 21, 2011

Jan. 21, 2011

A Wikipedia user has brought it to my attention that some of the terms for Indonesian islands used in the database are incorrect, archaic forms. The listings should be as follows. ID -0610+10648 Asia/Jakarta Java & Sumatra ID -0002+10920 Asia/Pontianak west & central Borneo ! ID -0507+11924 Asia/Makassar east & south Borneo, Sulawesi, Bali, Nusa Tenggara, west Timor ! ID -0232+14042 Asia/Jayapura western New Guinea, Maluku islands

1 0

Mercer County, N. D.
by Josh Findley Jan. 21, 2011

Jan. 21, 2011

In case you are not aware already, it appears that Mercer County, North Dakota, changed from the mountain time zone to the central time zone at the last transition from daylight-saving to standard time (on Nov. 7, 2010): http://www.gpo.gov/fdsys/pkg/FR-2010-09-29/html/2010-24376.htm http://www.bismarcktribune.com/news/local/article_1eb1b588-c758-11df-b472-0… Josh Findley

1 0

NYT: pressure to change UK clocks (no change yet)
by Eliot Lear Jan. 21, 2011

Jan. 21, 2011

New York Times reports Scottish opposition to a study to look at moving clocks forward an hour in the UK. http://www.nytimes.com/2011/01/21/world/europe/21inverness.html

3 2

Re: proposed time zone package changes
by Arthur David Olson Jan. 20, 2011

Jan. 20, 2011

I was able to check the 1933 Session Laws of Hawaii today; the revised "northamerica" changes below (against the current ftp version) reflect what I found. Also, in the "tz-art.htm" file, the addition of material on Ken Nordine (as well as the already circulated addition of material on Conan O'Brien). I still plan to update the ftp version on 2011-01-24. --ado diff -c -r old/northamerica new/northamerica *** old/northamerica Mon Nov 1 09:18:22 2010 --- new/northamerica Wed Jan 19 14:12:58 2011 *************** *** 1,5 **** # <pre> ! # @(#)northamerica 8.34 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)northamerica 8.37 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 471,490 **** # three votes for and one against." # Hawaii # ! # From Arthur David Olson: ! # And then there's Hawaii. ! # DST was observed for one day in 1933; ! # standard time was changed by half an hour in 1947; ! # it's always standard as of 1986. ! # ! # From Paul Eggert: ! # Shanks says the 1933 experiment lasted for three weeks. Go with Shanks. ! # ! Zone Pacific/Honolulu -10:31:26 - LMT 1900 Jan 1 12:00 ! -10:30 - HST 1933 Apr 30 2:00 ! -10:30 1:00 HDT 1933 May 21 2:00 ! -10:30 US H%sT 1947 Jun 8 2:00 -10:00 - HST # Now we turn to US areas that have diverged from the consensus since 1970. --- 471,520 ---- # three votes for and one against." # Hawaii + + # From Arthur David Olson (2010-12-09): + # "Hawaiian Time" by Robert C. Schmitt and Doak C. Cox appears on pages 207-225 + # of volume 26 of The Hawaian Journal of History (1992). As of 2010-12-09, + # the article is available at + # <a href="http://evols.library.manoa.hawaii.edu/bitstream/10524/239/2/JL26215.pdf"> + # http://evols.library.manoa.hawaii.edu/bitstream/10524/239/2/JL26215.pdf + # </a> + # and indicates that standard time was adopted effective noon, January + # 13, 1896 (page 218), that in "1933, the Legislature decreed daylight + # saving for the period between the last Sunday of each April and the + # last Sunday of each September, but less than a month later repealed the + # act," (page 220), that year-round daylight saving time was in effect + # from 1942-02-09 to 1945-09-30 (page 221, with no time of day given for + # when clocks changed) and that clocks were changed by 30 minutes + # effective the second Sunday of June, 1947 (page 219, with no time of + # day given for when clocks changed). A footnote for the 1933 changes + # cites Session Laws of Hawaii 1933, "Act. 90 (approved 26 Apr. 1933) + # and Act 163 (approved 21 May 1933)." + + # From Arthur David Olson (2011-01-19): + # The following is from "Laws of the Territory of Hawaii Passed by the + # Seventeenth Legislature: Regular Session 1933," available (as of + # 2011-01-19) at American University's Pence Law Library. Page 85: "Act + # 90...At 2 o'clock ante meridian of the last Sunday in April of each + # year, the standard time of this Territory shall be advanced one + # hour...This Act shall take effect upon its approval. Approved this 26th + # day of April, A. D. 1933. LAWRENCE M JUDD, Governor of the Territory of + # Hawaii." Page 172: "Act 163...Act 90 of the Session Laws of 1933 is + # hereby repealed...This Act shall take effect upon its approval, upon + # which date the standard time of this Territory shall be restored to + # that existing immediately prior to the taking effect of said Act 90. + # Approved this 21st day of May, A. D. 1933. LAWRENCE M. JUDD, Governor + # of the Territory of Hawaii." # ! # Note that 1933-05-21 was a Sunday. ! # We're left to guess the time of day when Act 163 was approved; guess noon. ! ! Zone Pacific/Honolulu -10:31:26 - LMT 1896 Jan 13 12:00 #Schmitt&Cox ! -10:30 - HST 1933 Apr 30 2:00 #Laws 1933 ! -10:30 1:00 HDT 1933 May 21 12:00 #Laws 1933+12 ! -10:30 1:00 HST 1942 Feb 09 2:00 #Schmitt&Cox+2 ! -10:30 - HDT 1945 Sep 30 2:00 #Schmitt&Fox+2 ! -10:30 US H%sT 1947 Jun 8 2:00 #Schmitt&Fox+2 -10:00 - HST # Now we turn to US areas that have diverged from the consensus since 1970. diff -c -r old/tz-art.htm new/tz-art.htm *** old/tz-art.htm Tue Oct 12 12:36:52 2010 --- new/tz-art.htm Wed Jan 19 13:47:16 2011 *************** *** 9,15 **** <body> <h1>Time and the Arts</h1> <address> ! @(#)tz-art.htm 8.17 </address> <p> This file is in the public domain, so clarified as of --- 9,15 ---- <body> <h1>Time and the Arts</h1> <address> ! @(#)tz-art.htm 8.19 </address> <p> This file is in the public domain, so clarified as of *************** *** 241,246 **** --- 241,257 ---- "The clocks were turned back you remeber/Think it's still November." </td></tr> <tr><td> </td></tr> + <tr><td>Artist</td><td>Ken Nordine</td></tr> + <tr><td>CD</td><td>You're Getting Better: The Word Jazz Dot Masters</td></tr> + <tr><td>Copyright Date</td><td>2005</td></tr> + <tr><td>Label</td><td>Geffen</td></tr> + <tr><td>ID</td><td>B0005171-02</td></tr> + <tr><td>Total Time</td><td>156:22</td></tr> + <tr><td>ADO Rating</td><td>1 star</td></tr> + <tr><td><a href="http://www.allmusic.com/album/youre-getting-better-the-word-jazz-dot-master…">AMG Rating</a></td><td>4.5 stars</td></tr> + <tr><td>Notes</td><td>Includes the piece "What Time Is It" + ("He knew what time it was everywhere...that counted").</td></tr> + <tr><td> </td></tr> <tr><td>TV episode title</td><td>The Lost Hour</td> <tr><td>TV series</td><td><em>Eerie, Indiana</em></td> *************** *** 467,472 **** --- 478,490 ---- It is already tomorrow in Australia." (Charles M. Schulz, provided by Steve Summit) </li> + <li> + "I put myself and my staff through this crazy, huge ordeal, all because + I refused to go on at midnight, okay? And so I work, you know, and + then I get this job at eleven, supposed to be a big deal. Then + yesterday daylight [saving] time ended. Right now it's basically + midnight." (Conan O'Brien on the 2010-11-08 premier of "Conan.") + </li> </ul> </body> </html>

4 4

Australian DST time incorrect
by Leo Griffiths Jan. 19, 2011

Jan. 19, 2011

Hi, I’m not sure if this is where I am supposed to report this so sorry if its not. I downloaded the files from the following site wget 'ftp://elsie.nci.nih.gov/pub/tz*.tar.gz' I checked the daylight savings times that were generated and found that they were incorrect for at least Sydney and Adelaide for at least this year. http://www.bom.gov.au/climate/averages/tables/dst_times.shtml This is the site for the Australian Bureau of Meteorology which lists all the current dates for DST in Australia to the current date. I hope this is helpful. Cheers, Leo

1 0