- tz - lists.iana.org

code question
by Zoidiasoft Tech Oct. 9, 2010

Oct. 9, 2010

Hi, I am a Delphi programmer and am working on a time zone problem. In the Olson database I'm having trouble differentiating between times that are strictly standard and those that include summer time / daylight savings. Is there a standard in the code for differentiating these? Most of it is fairly simple to understand but I am mystified by some of the abbreviations in the rule changes. For instance: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Finland 1942 only - Apr 3 0:00 1:00 S Rule Finland 1942 only - Oct 3 0:00 0 - Rule Finland 1981 1982 - Mar lastSun 2:00 1:00 S Rule Finland 1981 1982 - Sep lastSun 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Helsinki 1:39:52 - LMT 1878 May 31 1:39:52 - HMT 1921 May # Helsinki Mean Time 2:00 Finland EE%sT 1983 2:00 EU EE%sT What is the % symbol I keep seeing in the code for? For instance, in "2:00 EU EE%sT" is "EE%sT" Eastern European Standard Time? I take this to mean that Finland is currently on EU rules with a UTC offset of +2. Every now and then I also find something like this: "2:00 1:00 EEST 1989 Sep 24 2:00s" Does this line mean that I add 1 hour to the 2:00 hours UTC? Or is this correction already included in the 2 hours? Thanks! Sincerely, Curtis Manwaring

1 0

Samoa
by Olson, Arthur David (NIH/NCI) [E] Oct. 7, 2010

Oct. 7, 2010

Can anyone with boots on the ground tell us what actually happened with clock changes over the weekend in Samoa? Thanks. --ado

3 3

Valgrind error "Conditional jump or move depends on uninitialised value" on 64-bit
by Ravindra Oct. 5, 2010

Oct. 5, 2010

[Sending this directly to you because POSTing it on website does not seem to be working for me. This is about reproducing valgrind issue and a compilation warning.] Arthur and Paul, I'm seeing two problems in localtime.c: 1. When I compile localtime.c using gcc 4.1.2 for 32-bit, I get following warning: $ gcc -m32 -g -c -o localtime.o localtime.c localtime.c: In function âdiffer_by_repeatâ: localtime.c:326: warning: comparison is always false due to limited range of data type 2. valgrind reports following error for some timezones (only when localtime.c is compiled as 64-bit binary, it does not happen when compiled as 32-bit binary): ==26671== Conditional jump or move depends on uninitialised value(s) ==26671== at 0x401CDA: typesequiv (localtime.c:588) ==26671== by 0x401B85: tzload (localtime.c:562) ==26671== by 0x405553: tz_validate (localtime.c:2017) ==26671== by 0x40560D: main (localtime.c:2040) One can reproduce it using following valgrind command and patch: valgrind -v --tool=memcheck --leak-check=full --leak-resolution=med --show-reachable=yes --error-limit=no --workaround-gcc296-bugs=yes --run-libc-freeres=no --log-file=valgrind-tzvalid ./tzvalid /<path/to/my/zoneinfo/EST5EDT> NOTE: I can consistently reproduce it for EST5EDT timezone and I don't get this error for GMT. Patch for localtime.c for reproducing above error: --- org/localtime.c 2010-08-16 16:27:05.000000000 +0530 +++ localtime.c 2010-10-01 17:34:45.999089000 +0530 @@ -2004,6 +2004,47 @@ #endif /* defined CMUCS */ +static int +tz_validate(const char * name) +{ + struct state state = {0}; + time_t now; + struct tm tm; + + time(&now); + tzload(gmt, &state, TRUE); + if (0 == tzload(name, &state, TRUE)) { + localsub(&now, 0L, &tm); + return TRUE; + } + if (0 == tzparse(name, &state, FALSE)) { + localsub(&now, 0L, &tm); + return TRUE; + } + return FALSE; +} + +/* + * Compile it simply as "$gcc -m64 -g -o tzvalid localtime.c" + */ +int main(int argc, char ** argv) { + + if (argc != 2) { + printf("Usage: ./tzvalid <timezone_file_path>\n"); + return 2; + } + + char * tz = argv[1]; + + if (tz_validate(tz)) { + printf("timezone %s is valid\n", tz); + return 0; + } else { + printf("timezone %s is not valid\n", tz); + return 1; + } +} + /* ** XXX--is the below the right way to conditionalize?? */ Thanks in advance, Ravindra

1 0

Valgrind error "Conditional jump or move depends on uninitialised value" on 64-bit
by Ravindra Oct. 5, 2010

Oct. 5, 2010

I'm seeing two problems in localtime.c: 1. When I compile localtime.c using gcc 4.1.2 for 32-bit, I get following warning: $ gcc -m32 -g -c -o localtime.o localtime.c localtime.c: In function âdiffer_by_repeatâ: localtime.c:326: warning: comparison is always false due to limited range of data type 2. valgrind reports following error for some timezones (only when localtime.c is compiled as 64-bit binary, it does not happen when compiled as 32-bit binary): ==26671== Conditional jump or move depends on uninitialised value(s) ==26671== at 0x401CDA: typesequiv (localtime.c:588) ==26671== by 0x401B85: tzload (localtime.c:562) ==26671== by 0x405553: tz_validate (localtime.c:2017) ==26671== by 0x40560D: main (localtime.c:2040) One can reproduce it using following valgrind command and patch: valgrind -v --tool=memcheck --leak-check=full --leak-resolution=med --show- reachable=yes --error-limit=no --workaround-gcc296-bugs=yes --run-libc-freeres=no --log- file=valgrind-tzvalid ./tzvalid /<path/to/my/zoneinfo/EST5EDT> NOTE: I can consistently reproduce it for EST5EDT timezone and I don't get this error for GMT. Patch for localtime.c for reproducing above error: --- org/localtime.c 2010-08-16 16:27:05.000000000 +0530 +++ localtime.c 2010-10-01 17:34:45.999089000 +0530 @@ -2004,6 +2004,47 @@ #endif /* defined CMUCS */ +static int +tz_validate(const char * name) +{ + struct state state = {0}; + time_t now; + struct tm tm; + + time(&now); + tzload(gmt, &state, TRUE); + if (0 == tzload(name, &state, TRUE)) { + localsub(&now, 0L, &tm); + return TRUE; + } + if (0 == tzparse(name, &state, FALSE)) { + localsub(&now, 0L, &tm); + return TRUE; + } + return FALSE; +} + +/* + * Compile it simply as "$gcc -m64 -g -o tzvalid localtime.c" + */ +int main(int argc, char ** argv) { + + if (argc != 2) { + printf("Usage: ./tzvalid <timezone_file_path>\n"); + return 2; + } + + char * tz = argv[1]; + + if (tz_validate(tz)) { + printf("timezone %s is valid\n", tz); + return 0; + } else { + printf("timezone %s is not valid\n", tz); + return 1; + } +} + /* ** XXX--is the below the right way to conditionalize?? */ Thanks in advance, Ravindra

1 0

FW: About China time zones
by Olson, Arthur David (NIH/NCI) [E] Oct. 3, 2010

Oct. 3, 2010

I'm forwarding this message from Tom Korte, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. (While all of China is now officially in one time zone there were different zones until 1980; that's why there are multiple entries in the database. The database started out life with an entry for Chungking; the entry was later changed to use the Pinyin spelling Chongqing, but a Chungking link was kept for backward compatibility. And time zones are as a rule named for the city in the zone with the highest population--at the time the zone was named if not at present.) --ado From: Walter Korte [mailto:Walter.Korte@tomtom.com] Sent: Thursday, September 23, 2010 11:15 To: tz(a)lecserver.nci.nih.gov Subject: About China time zones To the maintainers of the tz database, We are using the TZ database in our navigation SW, and we have had feedback from our users in China that the time zone city names included do not make sense to local users. Neither Harbin, Shanghai nor Chungking (this is a very strange spelling, it is spelled Chongqing in Pinyin) is used in China to indicate a time zone. It would make most sense to remove these 3 entries and replace them with a single Beijing entry in the database. As HongKong and Macao are special administrative regions (SAR) in China, listing these makes sense. For the cities listed that are located in Xinjiang (Kashgar and Urumqi), these should not be listed as China only has one official time zone. But in practice Xinjiang uses its own time zone so keeping these would be better. Best regards, Walter Korte TomTom Asia

7 9

Cond jump or move depends on uninit'd value error on 64-bit Linux
by Ravindra Oct. 1, 2010

Oct. 1, 2010

I'm seeing two problems in localtime.c: 1. When I compile localtime.c using gcc 4.1.2 for 32-bit, I get following warning: $ gcc -m32 -g -c -o localtime.o localtime.c localtime.c: In function âdiffer_by_repeatâ: localtime.c:326: warning: comparison is always false due to limited range of data type 2. valgrind reports following error for some timezones (only when localtime.c is compiled as 64-bit binary, it does not happen when compiled as 32-bit binary): ==26671== Conditional jump or move depends on uninitialised value(s) ==26671== at 0x401CDA: typesequiv (localtime.c:588) ==26671== by 0x401B85: tzload (localtime.c:562) ==26671== by 0x405553: tz_validate (localtime.c:2017) ==26671== by 0x40560D: main (localtime.c:2040) One can reproduce it using following valgrind command and patch: valgrind -v --tool=memcheck --leak-check=full --leak-resolution=med --show- reachable=yes --error-limit=no --workaround-gcc296-bugs=yes --run-libc- freeres=no --log-file=valgrind-tzvalid ./tzvalid /<path/to/my/zoneinfo/EST5EDT> NOTE: I can consistently reproduce it for EST5EDT timezone and I don't get this error for GMT. Patch for localtime.c for reproducing above error: --- org/localtime.c 2010-08-16 16:27:05.000000000 +0530 +++ localtime.c 2010-10-01 17:34:45.999089000 +0530 @@ -2004,6 +2004,47 @@ #endif /* defined CMUCS */ +static int +tz_validate(const char * name) +{ + struct state state = {0}; + time_t now; + struct tm tm; + + time(&now); + tzload(gmt, &state, TRUE); + if (0 == tzload(name, &state, TRUE)) { + localsub(&now, 0L, &tm); + return TRUE; + } + if (0 == tzparse(name, &state, FALSE)) { + localsub(&now, 0L, &tm); + return TRUE; + } + return FALSE; +} + +/* + * Compile it simply as "$gcc -m64 -g -o tzvalid localtime.c" + */ +int main(int argc, char ** argv) { + + if (argc != 2) { + printf("Usage: ./tzvalid <timezone_file_path>\n"); + return 2; + } + + char * tz = argv[1]; + + if (tz_validate(tz)) { + printf("timezone %s is valid\n", tz); + return 0; + } else { + printf("timezone %s is not valid\n", tz); + return 1; + } +} + /* ** XXX--is the below the right way to conditionalize?? */ Thanks in advance, Ravindra

1 0

Re: zic and zoneinfo.zip
by Paul Eggert Oct. 1, 2010

Oct. 1, 2010

On 09/28/2010 11:15 PM, Ravindra wrote: > That's my appln code. It validates a timezone by loading it. It calls > tzload() like below: Can you please send a complete, self-contained test case illustrating the bug? Snippets of code from an otherwise unpublished help are nice, but they typically aren't enough to reproduce the problem.

2 2

environment independent time functions...
by christos＠zoulas.com Sept. 30, 2010

Sept. 30, 2010

Hello, What I want to achieve is to be able to use the time functions in a multi-threaded program that can handle multiple timezones at the same time. Right now, this is impossible, because the notion of timezone is expressed through the environment. I was careful to re-use the existing code and not change existing functionality so the following routines are just an add-on. I modified tzcode 2010l to add the following functions (as defined in timeextra.h). First I expose an opaque timezone type: typedef struct __state *timezone_t; which is no other than the internal state. Then I provide a way to allocate the handle on per timezone name and to free it. const timezone_t tzalloc(const char *); void tzfree(const timezone_t); Note that the handle is const, because I might want to enhance this in the future to use reference counting instead of allocating a new one per invocation. Then I provide a way to return the two (dst and nondst) strings (like tzname[0], and tzname[1]) with: const char * tzgetname(const timezone_t, int); The following functions are also provided, which are like the _r counterparts only they have an extra timezone argument: struct tm * localtime_z(const time_t *, struct tm *, const timezone_t); char * ctime_z(const time_t *, char *, const timezone_t); time_t timelocal_z(struct tm *, const timezone_t); time_t mktime_z(struct tm *, const timezone_t); time_t time2posix_z(time_t, const timezone_t); time_t posix2time_z(time_t, const timezone_t); The changes to the source are minimal (the diffs are slightly larger because I made things use ansi prototypes and removed 'register '. I don't care about the names or the signatures much, just something I came up as a proof of concept. Here's example code: #include "timeextra.h" #include <stdlib.h> #include <stdio.h> int main(int argc, char *argv[]) { size_t i; char buf[60]; time_t t = time(NULL); timezone_t *tz = malloc(argc * sizeof(*tz)); for (i = 1; i < argc; i++) { tz[i] = tzalloc(argv[i]); if (tz[i] == NULL) err(1, "Cannot find timezone %s", argv[i]); } for (i = 1; i < argc; i++) { printf("[%s] [%s] %s", tzgetname(tz[i], 0), tzgetname(tz[i], 1), ctime_z(&t, buf, tz[i])); tzfree(tz[i]); } return 0; } Has anyone done this work or similar? Do you think others might want something like this? Are you interested in taking a look at the changes/incorporating them? Do you have any other suggestions? Best Regards, christos

1 0

New TZ data for Fiji
by Franck Martin Sept. 29, 2010

Sept. 29, 2010

http://www.fiji.gov.fj/index.php?option=com_content&view=article&id=2438:da… Franck Martin http://www.avonsys.com/ http://www.facebook.com/Avonsys twitter: FranckMartin Avonsys Check your domain reputation: http://gurl.im/b69d4o

1 0

Re: Bug in zic.c?
by Arthur David Olson Sept. 29, 2010

Sept. 29, 2010

That is indeed a bug--in particular, in the DOWLEQ (<=) code. The bug wasn't triggered up to now since all the distributed rules use DOWGEQ (>=). Below is a proposed fix (and slight simplification). Note that the checks are needed to ensure that rules specified in the zic input are representable by POSIX environment variables. --ado ------- zic.c ------- *** /tmp/geta23934 Wed Sep 29 08:45:01 2010 --- /tmp/getb23934 Wed Sep 29 08:45:01 2010 *************** *** 3,9 **** ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.22"; #include "private.h" #include "locale.h" --- 3,9 ---- ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.23"; #include "private.h" #include "locale.h" *************** *** 1881,1896 **** register int week; if (rp->r_dycode == DC_DOWGEQ) { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if ((week - 1) * DAYSPERWEEK + 1 != rp->r_dayofmonth) return -1; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if (week * DAYSPERWEEK - 1 != rp->r_dayofmonth) return -1; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", --- 1881,1896 ---- register int week; if (rp->r_dycode == DC_DOWGEQ) { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 1) return -1; + week = 1 + rp->r_dayofmonth / DAYSPERWEEK; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 0) return -1; + week = rp->r_dayofmonth / DAYSPERWEEK; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d",

1 0