- tz - lists.iana.org

Chile's time zone data wrong
by ekrell＠tandem.cl Oct. 19, 1995

Oct. 19, 1995

Hi, I don't know if you're the right person, but your name is in Sun's /usr/share/lib/zoneinfo/southamerica file under Solaris 2.4 I wanted you to know that the rule for Chile is incorrect. This year, we switched to DST at midnight on Saturday, October 14th, but the rules in that file made our Suns switch to DST a week earlier. The reason for the discrepancy is that the rules in the file specify to switch to DST at 0:00 the second sunday of October. This year, October 1st was a sunday, so the second Sunday was October 8th. That's when our Suns switched to DST. However, the law says to switch to DST at midnight on the second SATURDAY of October, which is not the same as 0:00 on the second sunday of October. In fact, this year the bug showed up because October 1st was a Sunday... May I suggest to change the specification to Sun>=9 ? Eduardo Krell R&D Manager Tandem Chile S.A. Santiago ekrell(a)tandem.cl

2 1

Re: timezone stuff on 64 bit machines
by ado Oct. 18, 1995

Oct. 18, 1995

> It fixed that problem form my point of view -- meaning it comes out > of that loop. Now there's a hang in outzone() in zic.c. At line 1439 > it loops over every year once again. Here the solution may be in the "setboundaries" code in "zic.c". Since time zone files only encode four characters (32 bits) worth of time_t values, min_time and max_time (and min_year and max_year) might be limited. A cheap way to hot-wire things for testing purposes is to add the lines min_time = 0; max_time = 0x7fffffffL; just above the min_year = TM_YEAR_BASE + gmtime(&min_time)->tm_year; max_year = TM_YEAR_BASE + gmtime(&max_time)->tm_year; lines in "setboundaries" This begs the question of whether the format of time zone files would need to be changed to allow for 64-bit time_t values (with attendant interoperability considerations). --ado

1 0

Re: timezone stuff on 64 bit machines
by ado Oct. 18, 1995

Oct. 18, 1995

If someone with a 64-bit machine could check out the attached (and if everyone could check out the logic), I'd love it. --ado SCCS/s.localtime.c: 7.45 vs. 7.46 *** 7.45/localtime.c Wed Oct 18 16:36:18 1995 --- 7.46/localtime.c Wed Oct 18 16:36:20 1995 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.45"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.46"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1173,1178 **** --- 1173,1189 ---- if (tmp->tm_wday < 0) tmp->tm_wday += DAYSPERWEEK; y = EPOCH_YEAR; + #define CYCLE_DAYS 1022679L /* Any consecutive CYCLE_DAYS days... */ + #define CYCLE_YEARS 2800L /* make up exactly CYCLE_YEARS years. */ + if (days >= CYCLE_DAYS || days <= -CYCLE_DAYS) { + register int cycles; + + cycles = (days >= 0) ? + (days / CYCLE_DAYS) : + (-1 - (-1 - days) / CYCLE_DAYS); + days -= cycles * CYCLE_DAYS; + y += cycles * CYCLE_YEARS; + } if (days >= 0) for ( ; ; ) { yleap = isleap(y);

2 1

Re: timezone stuff on 64 bit machines
by ado Oct. 18, 1995

Oct. 18, 1995

> Is there a chance of getting a 64 bit fix for the timezone stuff? The fix is to use the fact that--at least for now--the calendar operates on a grand 2800-year cycle: any set of 2800 consecutive years contains exactly 1,022,679 days. A bit of modular arithmetic will get us where we want to be. --ado

2 1

timezone stuff on 64 bit machines
by Erik Troan Oct. 18, 1995

Oct. 18, 1995

I'm trying to use the timezone stuff you maintain on a 64-bit Alpha running Linux. It builds fine, but the timezone compiler has some trouble (it runs forever). I tracked the problem down to this code from timesub(): if (days >= 0) for ( ; ; ) { yleap = isleap(y); if (days < (long) year_lengths[yleap]) break; ++y; days = days - (long) year_lengths[yleap]; } else do { --y; yleap = isleap(y); days = days + (long) year_lengths[yleap]; } while (days < 0); This works fine when the number of years you can represent is small, as it is on a 32 bit machine. On a 64-bit machine however, you have some 4 billion more years to worry about. That means this loop has to repeat well over 4 billion times, and that takes 1 while :-) Any ideas on how to fix this? Erik ------------------------------------------------------------------------------- "Eggheads unite! You have nothing to lose but your yolks" - Adlai Stevenson Erik Troan = http://sunsite.unc.edu/ewt/ = ewt(a)sunsite.unc.edu

3 4

tzcode95e.tar.gz
by ado Oct. 13, 1995

Oct. 13, 1995

The mktime change to scan from future to past when trying to find time zone offsets has been incorporated into tzcode95e.tar.gz, available from elsie.nci.nih.gov (165.112.73.1) in the ~ftp/pub directory. --ado

1 0

time to retire SystemV?
by eggert＠twinsun.com Oct. 11, 1995

Oct. 11, 1995

I'm forwarding the following message originally posted to comp.os.linux.admin. Given the potential for confusion, perhaps it's time to comment-out the SystemV zones, for the same reason that US/Pacific-PET is commented out? Newsgroups: comp.os.linux.misc,comp.os.linux.admin From: davidsen(a)sixhub.tmr.com (Bill Davidsen) Subject: Who fixes broken timezones? Reply-To: davidsen(a)tmr.com (bill davidsen) Organization: TMR Associates, Schenectady NY Date: Mon, 9 Oct 1995 23:09:50 GMT Message-ID: <DG7F0G.43t(a)sixhub.tmr.com> This spring I posted a note saying the daylight savings time was broken. After about 50 people assured me it wasn't, Peter Dalgaard noted that "SystemV/EST5EDT" is broken and "US/Eastern" is not (guess most people use that). I just checked the 2.3 Slackware release and it's still wrong, so would someone tell me who maintains this so it can get fixed before it bites people again next year? Note: view the settings with zdump -v -c 2000 <filename> | grep 1995 the SystemV version thinks DST starts on the last Sunday of the month, not the first! -- TMR Associates, Inc +1 518 370-5654

1 0

Re: mktime problems when adjusting tm_isdst
by Bradley White Oct. 10, 1995

Oct. 10, 1995

I guess I would benefit from a succinct explanation of what mktime(`TZ=Europe/Paris 1996-01-01 00:00:00 tm_isdst=1') is supposed to mean. Paul's assertion ... > Surely the result should be > `1996-12-31 23:00:00 tm_isdst=0'. ..., while perhaps true, doesn't seem patently obvious. If I took `TZ=Europe/Paris 1995-06-01 00:00:00 tm_isdst=1', for example, and added six months, I think I would prefer to see a `1996-01-01 00:00:00 tm_isdst=0' mktime() result. In any case, a clear definition will tell us what to do with the code. Bradley

2 1

Re: mktime problems when adjusting tm_isdst
by ado Oct. 10, 1995

Oct. 10, 1995

We could run through the transition times from future to past (rather than from past to future as is done now); this doesn't solve the deep problem, but does get the "TZ=Europe/Paris 1996-01-01 00:00:00 tm_isdt=1" case right. It does have the advantage of being a fairly minimal change to the code. --ado *************** *** 1458,1467 **** if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ ! for (samei = 0; samei < sp->typecnt; ++samei) { if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; ! for (otheri = 0; otheri < sp->typecnt; ++otheri) { if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff - --- 1458,1467 ---- if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ ! for (samei = sp->typecnt - 1; samei >= 0; --samei) { if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; ! for (otheri = sp->typecnt - 1; otheri >= 0; --otheri) { if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff -

2 1

Re: mktime problems when adjusting tm_isdst
by Chris Torek Oct. 10, 1995

Oct. 10, 1995

>... and I worry that it might break some applications that assume >that tm_isdst==1 means ``use normal DST''. I think there may also be applications that use tm_isdst as a subscript into a two-element array. Breaking these could be considered doing them a favor, :-) Chris

1 0