The bad news is that there is indeed a code problem; the good news is that it was only introduced back in February of this year (with the first 64-bit-version release). The fix should be to move the zeroing of sp->timecnt; the suggested patch below incorporates both that change and a fix for last week's report on bad goahead/goback logic. (I've chosen the path of minimal change in both cases). --ado ------- localtime.c ------- *** /tmp/geta21479 Mon Jul 31 13:39:56 2006 --- /tmp/getb21479 Mon Jul 31 13:39:56 2006 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.3"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.5"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 556,564 **** } i = 2 * YEARSPERREPEAT; sp->goback = sp->goahead = sp->timecnt > i; ! sp->goback &= sp->types[i] == sp->types[0] && differ_by_repeat(sp->ats[i], sp->ats[0]); ! sp->goahead &= sp->types[sp->timecnt - 1] == sp->types[sp->timecnt - 1 - i] && differ_by_repeat(sp->ats[sp->timecnt - 1], sp->ats[sp->timecnt - 1 - i]); --- 556,564 ---- } i = 2 * YEARSPERREPEAT; sp->goback = sp->goahead = sp->timecnt > i; ! sp->goback = sp->goback && sp->types[i] == sp->types[0] && differ_by_repeat(sp->ats[i], sp->ats[0]); ! sp->goahead = sp->goahead && sp->types[sp->timecnt - 1] == sp->types[sp->timecnt - 1 - i] && differ_by_repeat(sp->ats[sp->timecnt - 1], sp->ats[sp->timecnt - 1 - i]); *************** *** 916,922 **** load_result = tzload(TZDEFRULES, sp, FALSE); if (load_result != 0) sp->leapcnt = 0; /* so, we're off a little */ - sp->timecnt = 0; if (*name != '\0') { if (*name == '<') { dstname = ++name; --- 916,921 ---- *************** *** 967,972 **** --- 966,972 ---- atp = sp->ats; typep = sp->types; janfirst = 0; + sp->timecnt = 0; for (year = EPOCH_YEAR; sp->timecnt + 2 <= TZ_MAX_TIMES; ++year) { -----Original Message----- From: David Lawless [mailto:lawless@spamcop.net] Sent: Friday, July 28, 2006 1:50 PM To: Olson, Arthur David (NIH/NCI) [E]; tz@lecserver.nci.nih.gov Subject: Question about 'tzparse()' Mr. Olson, I'm wondering about line 920 in 'tzparse()' in 'localtime.c': 917 load_result = tzload(TZDEFRULES, sp, FALSE); 918 if (load_result != 0) 919 sp->leapcnt = 0; /* so, we're off a little */ 920 sp->timecnt = 0; 921 if (*name != '\0') { 922 if (*name == '<') { 923 dstname = ++name; It appears to have the effect of inhibiting the application of DST per '/usr/local/etc/timezone/posixrules' when a TZ string such as TZ="EST+5EDT" is used. If the line is removed DST is applied. The effective default if 'posixrules' is not readable, per TZDEFRULESTRING, is TZ="EST+5EDT,M4.1.0,M10.5.0" which does lead to the application of DST. Also RHEL 4.3 (CentOS 4.3) appears to apply DST when TZ="EST+5EDT". Does 'tzparse()' behave in this manner by design? Thank you for your efforts and contribution of the excellent. zone package. Sincerely, David Lawless