- tz - lists.iana.org

Re: About China time zones
by Luther Ma Oct. 17, 2010

Oct. 17, 2010

I might also say here that adding a new population center in Xinjiang that is UTC +8:00 to the tz database (as originally suggested in "first pass at Uyghur time" 2009.11.21) is unnecessary and redundant (besides having other potential problems) because the population that uses +8:00 uses it precisely because they consider Beijing their center (which we, of course, call Shanghai/Asia). :P Just my opinion, of course. Once again, I'll accept "first pass" if it is to be the last pass. -mld

2 2

FW: environment independent time functions...
by Olson, Arthur David (NIH/NCI) [E] Oct. 14, 2010

Oct. 14, 2010

I'm forwarding this message from Christos Zoulas, 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: Christos Zoulas [mailto:christos@zoulas.com] Sent: Thursday, September 30, 2010 4:36 To: tz(a)lecserver.nci.nih.gov Subject: environment independent time functions... 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

6 7

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

Oct. 13, 2010

I'm forwarding this message from Raymond Hughes, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. (Right now http://www.mcil.gov.ws is unavailable--at least from the system I'm using--but Googling "03/04/11 adjust clocks" and using the "Cache" link provides the content). --ado -----Original Message----- From: Raymond Hughes [mailto:raymond@hughes.ws] Sent: Thursday, October 07, 2010 9:36 To: tz(a)lecserver.nci.nih.gov Subject: Re: Samoa the start of DST here is Samoa was OK from what I've seen, but looking at my zdump I see the ending does not have the correct times. Sun Sep 26 10:59:59 2010 UTC = Sat Sep 25 23:59:59 2010 WST isdst=0 Sun Sep 26 11:00:00 2010 UTC = Sun Sep 26 01:00:00 2010 WSDT isdst=1 Sun Apr 3 09:59:59 2011 UTC = Sat Apr 2 23:59:59 2011 WSDT isdst=1 Sun Apr 3 10:00:00 2011 UTC = Sat Apr 2 23:00:00 2011 WST isdst=0 Please see www.mcil.gov.ws, the Ministry of Commerce, Industry and Labour (sideframe) "Last Sunday September 2010 (26/09/10) - adjust clocks forward from 12:00 midnight to 01:00am and First Sunday April 2011 (03/04/11) - adjust clocks backwards from 1:00am to 12:00am" PS. Thanks Maintainers Regards Ray

3 3

Re Fiji Timezone
by Franck Martin Oct. 13, 2010

Oct. 13, 2010

Seems the TZ file is not updated with the info: http://www.fiji.gov.fj/index.php?option=com_content&view=article&id=2438:da… Fiji will switch back to daylight saving time from 24th October, 2010 at 2am. This means members of the public will be required to switch their clocks one hour ahead to 3am. It is expected to end in March 2011, a date is yet to be confirmed. Franck Martin http://www.avonsys.com/ http://www.facebook.com/Avonsys twitter: FranckMartin Avonsys Check your domain reputation: http://gurl.im/b69d4o

1 0

Australia has changed the first day of daylight?
by Ahmed Hassan (ahmhassa) Oct. 13, 2010

Oct. 13, 2010

Dear, Since last year, Australia has changed the first day of daylight saving to the first Sunday of October, and ending first Sunday of April. Here is the URL for your reference for states specific changes: http://www.bom.gov.au/climate/averages/tables/dst_times.shtml, which version does capture this change? Best regards, Ahmed

1 0

A question about Amsterdam in 1900
by David Patte Oct. 10, 2010

Oct. 10, 2010

I was reviewing some historical zones & rules, and I can across a date for Amsterdam that has me a bit confused. I'm not sure if I'm misinterpreting the records, or whether a record is missing. Lets take Jan 1, 1900 for Amsterdam. The Zone table for Europe/Amsterdam shows: a GMT offset of 0:19:32 (and no rule) until 1835, then a GMT offset of 0:19:32 (and Neth rule) until July 1 1937 - using '%s' for letters So for Jan 1, 1900 I am assuming I should be looking for a rule in the Neth rules records But the first 'Neth' Rule starts 1916. I can easily easily understand that this means that there is no special save amount to apply on Jan 1st 1900, but what letters should I be using for that date given that the zone says the letters should be %s? Since the zone record says '%s' for that date, should there not be a rule record starting in 1835 that gives a save amount of 0, and provides the letters 'AMT'? Thanks

2 1

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. 8, 2010

Oct. 8, 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. 4, 2010

Oct. 4, 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. 30, 2010

Sept. 30, 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

FW: Bug in zic.c?
by Olson, Arthur David (NIH/NCI) [E] Sept. 29, 2010

Sept. 29, 2010

I'm forwarding this message from Lei Liu, 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: Liu, Lei [mailto:lei.liu2@windriver.com] Sent: Wednesday, September 29, 2010 4:17 To: tz(a)lecserver.nci.nih.gov Subject: Bug in zic.c? Hi, I have a question about the code in zic.c. In function stringrule I get: week = 1 + rp->r_dayofmonth / DAYSPERWEEK; if ((week - 1) * DAYSPERWEEK + 1 != rp->r_dayofmonth) return -1; //... week = 1 + rp->r_dayofmonth / DAYSPERWEEK; if (week * DAYSPERWEEK - 1 != rp->r_dayofmonth) return -1; What do these two if check here? The first one passes only when rp->r_dayofmonth mod 7 equals to 1. And the second one passes only when rp->r_dayofmonth mode 7 equals to 6. But IMO rp->r_dayofmonth can be arbitrary valid day number of the month. This question came up with a problem of compiling following input file: #RULE NAME FROM TO TYPE IN ON AT SAVE LTRS Rule localtime minimum maximum - Mar Sun<=14 2:00 1:0 PDT Rule localtime minimum maximum - Nov Sun<=7 2:00 0:0 UTC # ZONE NAME GMTOFF RULES/SAVE FORMAT Zone localtime 0:0 localtime %s zic prints out: "fault.txt", line 6: too many transitions?! (rule from "fault.txt", line 2) After I removed the two if check, this file can be successfully processed. Is this problem caused by a bug in zic.c or the invalid input data. Thanks. Lei

1 0

Bug in zic.c?
by Liu, Lei Sept. 29, 2010

Sept. 29, 2010

Hi, I have a question about the code in zic.c. In function stringrule I get: week = 1 + rp->r_dayofmonth / DAYSPERWEEK; if ((week - 1) * DAYSPERWEEK + 1 != rp->r_dayofmonth) return -1; //... week = 1 + rp->r_dayofmonth / DAYSPERWEEK; if (week * DAYSPERWEEK - 1 != rp->r_dayofmonth) return -1; What do these two if check here? The first one passes only when rp->r_dayofmonth mod 7 equals to 1. And the second one passes only when rp->r_dayofmonth mode 7 equals to 6. But IMO rp->r_dayofmonth can be arbitrary valid day number of the month. This question came up with a problem of compiling following input file: #RULE NAME FROM TO TYPE IN ON AT SAVE LTRS Rule localtime minimum maximum - Mar Sun<=14 2:00 1:0 PDT Rule localtime minimum maximum - Nov Sun<=7 2:00 0:0 UTC # ZONE NAME GMTOFF RULES/SAVE FORMAT Zone localtime 0:0 localtime %s zic prints out: "fault.txt", line 6: too many transitions?! (rule from "fault.txt", line 2) After I removed the two if check, this file can be successfully processed. Is this problem caused by a bug in zic.c or the invalid input data. Thanks. Lei

1 0

FW: FW: zic and zoneinfo.zip
by Olson, Arthur David (NIH/NCI) [E] Sept. 28, 2010

Sept. 28, 2010

I'm forwarding this message from Ravindra, 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: Ravindra [mailto:rsahlot@yahoo.com] Sent: Monday, September 27, 2010 8:09 To: 'tz(a)elsie.nci.nih.gov'; Olson, Arthur David (NIH/NCI) [E] Subject: Re: FW: zic and zoneinfo.zip More testing on this revealed that it happens only when I use tzdata from version "2010l" on a 64-bit platform (localtime.c compiled as 64-bit code). valgrind does not report the memory error if localtime.c is compiled as 32-bit code or if I use tzdata2007k with tzcode2010l. Looks like, tzcode2010l and tzdata2010l do not get well together on 64-bit? Thanks, Ravindra --- On Sat, 9/25/10, Olson, Arthur David (NIH/NCI) [E] <olsona(a)dc37a.nci.nih.gov> wrote: > From: Olson, Arthur David (NIH/NCI) [E] <olsona(a)dc37a.nci.nih.gov> > Subject: FW: zic and zoneinfo.zip > To: "'tz(a)elsie.nci.nih.gov'" <tz(a)elsie.nci.nih.gov> > Cc: "'rsahlot(a)yahoo.com'" <rsahlot(a)yahoo.com> > Date: Saturday, September 25, 2010, 6:11 PM > I'm forwarding this message from > Ravindra, who is not on the time zone mailing list. Those of > you who are on the list, please direct replies > appropriately. > > (Note that the line numbers below are indeed different from > those in the 2010l on elsie.nci.nih.gov, and that there's no > "tz.c" file with a "tz_validate" function in 2010l on > elsie.nci.nih.gov.) > > > --ado > > -----Original Message----- > From: Ravindra [mailto:rsahlot@yahoo.com] > > Sent: Saturday, September 25, 2010 8:01 > To: Olson, Arthur David (NIH/NCI) [E] > Subject: RE: zic and zoneinfo.zip > > Thanks Arthur! > > Is there a place where I get pre-built zic binary for > Linux? > > I got the doubt because I could build 32-bit zic as well as > 64-bit zic from source code, and I was not sure whether to > build zic as a 32-bit binary or 64-bit binary. What I'm > getting from your response is I can use either version of > zic and use the generated timezone data files on either > platform. > > BTW, I'm looking at various possibilities because I'm using > the code and data from version "2010l" and I'm hitting > following memory error in valgrind log: > > ==5207== Thread 27: > ==5207== Conditional jump or move depends on uninitialised > value(s) > ==5207== at 0x1B9F988: typesequiv > (localtime.c:522) > ==5207== by 0x1B9F830: tzload > (localtime.c:493) > ==5207== by 0x1BA261B: tz_validate > (tz.c:1717) > > Below call is hitting above memory error (line numbers may > not match with original code because we have integrated it > in our code): > > 1712 struct > state state = {0}; > 1713 time_t > > now; > 1714 struct tm > tm; > 1715 > 1716 time(&now); > *** 1717 tzload(gmt, > &state, TRUE, 0); > ... > > tzload code: > ... > 486 if > (sp->timecnt > 1) { > 487 > for (i = 1; i < sp->timecnt; ++i) > 488 > if (typesequiv(sp, > sp->types[i], sp->types[0]) && > 489 > > differ_by_repeat(sp->ats[i], > sp->ats[0])) { > 490 > > sp->goback = > TRUE; > 491 > > break; > 492 > > } > **** 493 > for (i = sp->timecnt - 2; i >= 0; > --i) > 494 > if (typesequiv(sp, > sp->types[sp->timecnt - 1], > 495 > > sp->types[i]) && > 496 > > differ_by_repeat(sp->ats[sp->timecnt > - 1], > 497 > > sp->ats[i])) { > 498 > > sp->goahead = > TRUE; > 499 > > break; > 500 > } > 501 } > ... > 511 static int > 512 typesequiv(const struct state * const sp, const int a, > const int b) > 513 { > 514 register > int result; > 515 > 516 if (sp == NULL > || > 517 > a < 0 || a >= sp->typecnt || > 518 > b < 0 || b >= sp->typecnt) > 519 > result = FALSE; > 520 else { > 521 > register const struct ttinfo * ap = > &sp->ttis[a]; > *** 522 > register const struct ttinfo * bp = > &sp->ttis[b]; > 523 > result = ap->tt_gmtoff == > bp->tt_gmtoff && > 524 > ap->tt_isdst == > bp->tt_isdst && > 525 > ap->tt_ttisstd == > bp->tt_ttisstd && > 526 > ap->tt_ttisgmt == > bp->tt_ttisgmt && > 527 > > strcmp(&sp->chars[ap->tt_abbrind], > 528 > > &sp->chars[bp->tt_abbrind]) == > 0; > 529 } > 530 return result; > 531 } > > It will be great if you are aware of fix for this or if you > could help me how to proceed on this. I can explore this > further but I'm new to this code. > > Thanks in advance, > Ravindra > > --- On Fri, 9/24/10, Olson, Arthur David (NIH/NCI) [E] > <olsona(a)dc37a.nci.nih.gov> > wrote: > > > From: Olson, Arthur David (NIH/NCI) [E] <olsona(a)dc37a.nci.nih.gov> > > Subject: RE: zic and zoneinfo.zip > > To: "Ravindra" <rsahlot(a)yahoo.com> > > Date: Friday, September 24, 2010, 6:40 PM > > The current version of zic generates, > > for each time zone, a binary file that includes both > 32-bit > > and 64-bit versions of the zone's data; the binary > files > > should be usable on both 32- and 64-bit systems. > > > > --ado > > > >

3 4

FW: zic and zoneinfo.zip
by Olson, Arthur David (NIH/NCI) [E] Sept. 28, 2010

Sept. 28, 2010

I'm forwarding this message from Ravindra, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. (Note that the line numbers below are indeed different from those in the 2010l on elsie.nci.nih.gov, and that there's no "tz.c" file with a "tz_validate" function in 2010l on elsie.nci.nih.gov.) --ado -----Original Message----- From: Ravindra [mailto:rsahlot@yahoo.com] Sent: Saturday, September 25, 2010 8:01 To: Olson, Arthur David (NIH/NCI) [E] Subject: RE: zic and zoneinfo.zip Thanks Arthur! Is there a place where I get pre-built zic binary for Linux? I got the doubt because I could build 32-bit zic as well as 64-bit zic from source code, and I was not sure whether to build zic as a 32-bit binary or 64-bit binary. What I'm getting from your response is I can use either version of zic and use the generated timezone data files on either platform. BTW, I'm looking at various possibilities because I'm using the code and data from version "2010l" and I'm hitting following memory error in valgrind log: ==5207== Thread 27: ==5207== Conditional jump or move depends on uninitialised value(s) ==5207== at 0x1B9F988: typesequiv (localtime.c:522) ==5207== by 0x1B9F830: tzload (localtime.c:493) ==5207== by 0x1BA261B: tz_validate (tz.c:1717) Below call is hitting above memory error (line numbers may not match with original code because we have integrated it in our code): 1712 struct state state = {0}; 1713 time_t now; 1714 struct tm tm; 1715 1716 time(&now); *** 1717 tzload(gmt, &state, TRUE, 0); ... tzload code: ... 486 if (sp->timecnt > 1) { 487 for (i = 1; i < sp->timecnt; ++i) 488 if (typesequiv(sp, sp->types[i], sp->types[0]) && 489 differ_by_repeat(sp->ats[i], sp->ats[0])) { 490 sp->goback = TRUE; 491 break; 492 } **** 493 for (i = sp->timecnt - 2; i >= 0; --i) 494 if (typesequiv(sp, sp->types[sp->timecnt - 1], 495 sp->types[i]) && 496 differ_by_repeat(sp->ats[sp->timecnt - 1], 497 sp->ats[i])) { 498 sp->goahead = TRUE; 499 break; 500 } 501 } ... 511 static int 512 typesequiv(const struct state * const sp, const int a, const int b) 513 { 514 register int result; 515 516 if (sp == NULL || 517 a < 0 || a >= sp->typecnt || 518 b < 0 || b >= sp->typecnt) 519 result = FALSE; 520 else { 521 register const struct ttinfo * ap = &sp->ttis[a]; *** 522 register const struct ttinfo * bp = &sp->ttis[b]; 523 result = ap->tt_gmtoff == bp->tt_gmtoff && 524 ap->tt_isdst == bp->tt_isdst && 525 ap->tt_ttisstd == bp->tt_ttisstd && 526 ap->tt_ttisgmt == bp->tt_ttisgmt && 527 strcmp(&sp->chars[ap->tt_abbrind], 528 &sp->chars[bp->tt_abbrind]) == 0; 529 } 530 return result; 531 } It will be great if you are aware of fix for this or if you could help me how to proceed on this. I can explore this further but I'm new to this code. Thanks in advance, Ravindra --- On Fri, 9/24/10, Olson, Arthur David (NIH/NCI) [E] <olsona(a)dc37a.nci.nih.gov> wrote: > From: Olson, Arthur David (NIH/NCI) [E] <olsona(a)dc37a.nci.nih.gov> > Subject: RE: zic and zoneinfo.zip > To: "Ravindra" <rsahlot(a)yahoo.com> > Date: Friday, September 24, 2010, 6:40 PM > The current version of zic generates, > for each time zone, a binary file that includes both 32-bit > and 64-bit versions of the zone's data; the binary files > should be usable on both 32- and 64-bit systems. > > --ado

5 8

FW: FW: Time Zone in Paris
by Olson, Arthur David (NIH/NCI) [E] Sept. 25, 2010

Sept. 25, 2010

I'm forwarding this message from Katia, who is not the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado -----Original Message----- From: Katia [mailto:katia@astrologiainlinea.it] Sent: Saturday, September 25, 2010 6:44 To: 'Paul Eggert' Cc: tz(a)lecserver.nci.nih.gov Subject: R: FW: Time Zone in Paris Thank you for your reply and for having put my question in the mailing lists to which I will enjoy soon. The problem is that according to the downloaded version of the database on the Google site for updates http://code.google.com/p/tzdata/ in 1971 the time zone in Paris wasn't one hour ahead of UTC. Here is part of Paris file in XML version <from>1945-04-02T01:00:00Z</from> <to>1945-09-16T01:00:00Z</to> <dst>true</dst> <offset>7200</offset> <name>WEMT</name> </period> - <period> <from>1945-09-16T01:00:00Z</from> <to>1976-03-28T01:00:00Z</to> <dst>false</dst> <offset>0</offset> <name>WET</name> </period> - <period> Is that file correct ? Katia -----Messaggio originale----- Da: Paul Eggert [mailto:eggert@cs.ucla.edu] Inviato: giovedì 23 settembre 2010 06:37 A: katia(a)astrologiainlinea.it Cc: tz(a)elsie.nci.nih.gov Oggetto: Re: FW: Time Zone in Paris Katia wrote: > With regard to the time zone of Paris from 1945 to 1976 it results a > strange data that conflicts over other resources credited as Shank, > according to your database in 1971 the Time zone Paris was 0. Sorry, I don't see that problem. According to the tz database, the time zone in Paris was one hour ahead of UTC during that period. This agrees with Shanks & Pottenger 2003 (ISBN 0-035127-88-7); I just now checked my printed copy. It also agrees with the Ephemerides Astronomiques for 1998 from Bureau des Longitudes, according to email that we received on 1997-12-12 from Denis Excoffier. These two sources disagree only about exactly when this long period of UTC+1 ended. Shanks & Pottenger say that it ended on 1976-03-28 at 02:00 local time, whereas Excoffier wrote that it ended at 00:00 UTC, i.e., at 01:00 local time. Currently the tz database agrees with Excoffier, but we always welcome any more-authoritative sources, such as reliable newspapers published at the time.

2 1

FW: Time Zone in Paris
by Olson, Arthur David (NIH/NCI) [E] Sept. 25, 2010

Sept. 25, 2010

I'm forwarding this message from Katia, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado From: Katia [mailto:katia@astrologiainlinea.it] Sent: Wednesday, September 22, 2010 6:31 To: tz(a)lecserver.nci.nih.gov Subject: Time Zone in Paris Hello, we use your database to make astrological calculations. With regard to the time zone of Paris from 1945 to 1976 it results a strange data that conflicts over other resources credited as Shank, according to your database in 1971 the Time zone Paris was 0. Can you confirm this and show me the source? Thanks and good job Katia

4 3

zic and zoneinfo.zip
by Ravindra Sept. 24, 2010

Sept. 24, 2010

We use tzcode and tzdata in our app. We are adding support for 64-bit platforms (Windows and Linux) in our app. I would like to know the right way to generate zoneinfo.zip from tzdata2010l.tar.gz (using "zic -d" command). I have following doubts: 1. Is it ok to use same zoneinfo.zip for 32-bit as well as 64-bit platform? 2. Do I need to build two zic (32-bit and 64-bit) binaries in order to generate separate zoneinfo.zip files for 32-bit and 64-bit platforms? 3. If same zoneinfo.zip can be used for both the platforms, which zic should I use to generate the zoneinfo.zip (32-bit zic or 64-bit zic)? Could someone please clarify my doubts above? Thanks in advance, Ravindra

1 0

About China time zones
by Walter Korte Sept. 24, 2010

Sept. 24, 2010

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

1 0

FW: Time Zone in Paris
by Francis SANTONI Sept. 23, 2010

Sept. 23, 2010

Hello, France uses 'de facto' Eastern time zone 1h. This transition has occurred by a switch to summer time in February 1940. There never was back in the winter time at the time of the meridian of Greenwich. France adopted DST in 1976 (Official Decree number 75 866 on September 19, 1975) so that some say France uses a simple summer time in winter and double summer time in summer but in practice its official time for winter is UT + 1hr East and summer time is UT +2hr East. (Sorry but I do not understand the interest of abbreviations given to time zones). Francis Santoni, Paris

1 0