- tz - lists.iana.org

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

mktime problems when adjusting tm_isdst
by Paul Eggert Oct. 10, 1995

Oct. 10, 1995

With TZ=Europe/Paris, when I invoke mktime on the equivalent of `1996-01-01 00:00:00 tm_isdst=1', it returns the equivalent of `1995-12-31 23:09:21 tm_isdst=0'. Surely the result should be `1996-12-31 23:00:00 tm_isdst=0'. (This is tzcode95d compiled on Solaris 2.4.) The problem seems to be that mktime discovers that the requested time exists only in standard time, so it corrects it by subtracting the first known GMT offset using DST and adding the first known GMT offset not using DST. But Europe/Paris currently uses different DST rules (and a different GMT offset) than it did in 1916 and 1911, respectively. The obvious workaround for this case is to change time1() so that it uses the nearest DST and non-DST transitions just before the requested time, instead of the first possible DST and non-DST transitions. But this breaks down in other cases. For example, in Europe/Paris at 1940-06-15 00:00:00, the GMT offset is 2 hours, tm_isdst=1 and there's a 1-hour DST offset, but at the most recent non-DST period the GMT offset is 0 hours, so mktime will wrongly adjust the time by 2 hours. There's a deeper problem here. How should mktime adjust for DST in a locale that has multiple DST offsets? For example, suppose TZ=America/St_Johns and I invoke mktime on the equivalent of `1989-01-01 00:00:00 tm_isdst=1'. Newfoundland used a 2-hour DST offset in summer 1988 and a 1-hour DST offset in summer 1989, so should the requested time be adjusted by 1 hour or by 2? One possible way to address the deeper problem, suggested by Mark Brader, is to represent different DST offsets by using different tm_isdst values. For example, instead of simply being 1 when some sort of DST is in effect, tm_isdst could be the DST offset, in seconds modulo INT_MAX+1. That way, mktime can tell which DST offset was used to derive its input time, and it can adjust the time correctly when it finds that a different DST offset is needed. I think this change would make it easy to fix the Europe/Paris bug mentioned above. But it's a nontrivial change to the tz code and I worry that it might break some applications that assume that tm_isdst==1 means ``use normal DST''. Here's a test program to reproduce the bug describe above. Run it with TZ set to Europe/Paris as built from tzdata95i.tar.gz, and give it the arguments `1996-01-01 00:00:00 1'. #include <stdio.h> #include <time.h> #define TM_YEAR_BASE 1900 static void print_tm (tp) struct tm *tp; { printf ("%04d-%02d-%02d %02d:%02d:%02d yday %03d wday %d isdst %d", tp->tm_year + TM_YEAR_BASE, tp->tm_mon + 1, tp->tm_mday, tp->tm_hour, tp->tm_min, tp->tm_sec, tp->tm_yday, tp->tm_wday, tp->tm_isdst); } int main (argc, argv) int argc; char **argv; { time_t t; struct tm tm; char trailer; if (argc == 4 && (sscanf (argv[1], "%d-%d-%d%c", &tm.tm_year, &tm.tm_mon, &tm.tm_mday, &trailer) == 3) && (sscanf (argv[2], "%d:%d:%d%c", &tm.tm_hour, &tm.tm_min, &tm.tm_sec, &trailer) == 3) && (sscanf (argv[3], "%d%c", &tm.tm_isdst, &trailer) == 1)) { tm.tm_year -= TM_YEAR_BASE; tm.tm_mon--; t = mktime (&tm); printf ("mktime returns %ld == ", (long) t); print_tm (&tm); printf ("\n"); } else printf ("Usage:\t%s YYYY-MM-DD HH:MM:SS ISDST # Test given time.\n", argv[0]); return 0; }

1 0

Re: When should Canada/Central return to Standard Time?
by ado Sept. 26, 1995

Sept. 26, 1995

> Given Shanks's data, I'd guess that the Sun customer's ``one week too > early'' was just a approximation, and the true error is one month too > early. This is consistent with the rest of Canada. Here is a > proposed patch. The suggested has been incorporated into tzdata95i.tar.gz, available by anonymous ftp from the ~ftp/pub directory on elsie.nci.nih.gov (165.112.73.1). --ado

1 0

Re: When should Canada/Central return to Standard Time?
by Paul Eggert Sept. 26, 1995

Sept. 26, 1995

I consulted Shanks and found that I transcribed his data for Winnipeg incorrectly, not only for this year, but also for 1937, 1948, 1950, 1963, and all years from 1966 on. Sorry about that -- I must have forgotten to proofread Winnipeg originally. (At least I didn't misspell its name as ``Winnepeg''....) Given Shanks's data, I'd guess that the Sun customer's ``one week too early'' was just a approximation, and the true error is one month too early. This is consistent with the rest of Canada. Here is a proposed patch. =================================================================== RCS file: RCS/northamerica,v retrieving revision 1995.8 retrieving revision 1995.8.1.1 diff -c -r1995.8 -r1995.8.1.1 *** northamerica 1995/09/21 15:26:26 1995.8 --- northamerica 1995/09/26 10:36:47 1995.8.1.1 *************** *** 464,484 **** Rule Winn 1918 only - Apr 14 2:00 1:00 D Rule Winn 1918 only - Oct 31 2:00 0 S Rule Winn 1937 only - May 16 2:00 1:00 D ! Rule Winn 1937 only - Sep 23 2:00 0 S Rule Winn 1942 only - Feb 9 2:00 1:00 D Rule Winn 1945 only - Sep lastSun 2:00 0 S Rule Winn 1946 only - May 12 2:00 1:00 D Rule Winn 1946 only - Oct 13 2:00 0 S Rule Winn 1947 1949 - Apr lastSun 2:00 1:00 D ! Rule Winn 1947 1958 - Sep lastSun 2:00 0 S ! Rule Winn 1948 only - May 1 2:00 1:00 D ! Rule Winn 1948 1960 - Apr lastSun 2:00 1:00 D Rule Winn 1959 only - Oct lastSun 2:00 0 S Rule Winn 1960 only - Sep lastSun 2:00 0 S Rule Winn 1963 only - Apr lastSun 2:00 1:00 D ! Rule Winn 1963 only - Sep lastSun 2:00 0 S Rule Winn 1966 1986 - Apr lastSun 2:00 1:00 D ! Rule Winn 1966 max - Sep lastSun 2:00 0 S Rule Winn 1987 max - Apr Sun>=1 2:00 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Winnipeg -6:28:36 - LMT 1887 Jul 16 --- 464,486 ---- Rule Winn 1918 only - Apr 14 2:00 1:00 D Rule Winn 1918 only - Oct 31 2:00 0 S Rule Winn 1937 only - May 16 2:00 1:00 D ! Rule Winn 1937 only - Sep 26 2:00 0 S Rule Winn 1942 only - Feb 9 2:00 1:00 D Rule Winn 1945 only - Sep lastSun 2:00 0 S Rule Winn 1946 only - May 12 2:00 1:00 D Rule Winn 1946 only - Oct 13 2:00 0 S Rule Winn 1947 1949 - Apr lastSun 2:00 1:00 D ! Rule Winn 1947 1949 - Sep lastSun 2:00 0 S ! Rule Winn 1950 only - May 1 2:00 1:00 D ! Rule Winn 1950 only - Sep 30 2:00 0 S ! Rule Winn 1951 1960 - Apr lastSun 2:00 1:00 D ! Rule Winn 1951 1958 - Sep lastSun 2:00 0 S Rule Winn 1959 only - Oct lastSun 2:00 0 S Rule Winn 1960 only - Sep lastSun 2:00 0 S Rule Winn 1963 only - Apr lastSun 2:00 1:00 D ! Rule Winn 1963 only - Sep 22 2:00 0 S Rule Winn 1966 1986 - Apr lastSun 2:00 1:00 D ! Rule Winn 1966 max - Oct lastSun 2:00 0 S Rule Winn 1987 max - Apr Sun>=1 2:00 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Winnipeg -6:28:36 - LMT 1887 Jul 16

1 0

Is the current Canada/Central zoneinfo correct?
by unknown＠example.com Sept. 25, 1995

Sept. 25, 1995

I am the guy who maintains the zoneinfo stuff in Solaris 2 and one of our customers just submitted a bug against the current Canada/Central (aka America/Winnepeg) entry complaining that it switches back to Standard Time one week too early. The current entry for Canada/Central says that it should switch on the last Sunday in September, which would have been yesterday, the 24th. Who is right? Our customer or the current zoneinfo source? alan perry

2 1

Re: Is the current Canada/Central zoneinfo correct?
by ado Sept. 25, 1995

Sept. 25, 1995

I called Tourism Winnipeg, (800) 665-0204, at 8:55 p.m. GMT on 9/25/95 (4:55 p.m. in Washington, DC; US Eastern Daylight Time, the same as New York). The answering party said it was 3:55 in Winnipeg; Winnipeg being Central, this one-hour difference would indicate they're also still on Daylight Time. The current "northamerica" file yields a two-hour difference, and shows Winnipeg back on Standard Time (indicated by the "CST" below): Script started on Mon Sep 25 17:19:30 1995 elsie$ ./zdump GMT America/New_York America/Winnipeg GMT Mon Sep 25 21:19:41 1995 GMT America/New_York Mon Sep 25 17:19:41 1995 EDT America/Winnipeg Mon Sep 25 15:19:41 1995 CST elsie$ exit script done on Mon Sep 25 17:19:45 1995 So it does look as if something is amiss. Whether it's the rule or the answering party, what the right rule is, and what area the right rule applies in deponent sayeth not. --ado

1 0