- tz - lists.iana.org

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

Feb. 15, 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. 12, 2011

Feb. 12, 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. 12, 2011

Feb. 12, 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