March 1997 - tz - lists.iana.org

Changes in Israel's 1997 Daylight Savings Rules
by Ephraim Silverberg March 3, 1997

March 3, 1997

Yesterday, the Knesset (Israeli parliament) passed a law changing the daylight savings changeover times for 1997 (a mere ten days from when the old times were to take effect). Attached is the new Zic file for Israel with the corrected 1997 times. For now, the times for 1998 remain the same and there are no official times for 1999 and on. Please note that I have altered some of the comments as well. The official announcement (in Hebrew) is in the gzipped postscript file: ftp://ftp.huji.ac.il/pub/tz/announcements/1997.ps.gz An article from the English-language Jerusalem Post of late January explains the rational for the change and can be found in: ftp://ftp.huji.ac.il/users/ephraim/tz/timezone97.ps.gz Please note that the starting time mentioned in the English-language article is NOT the time that was finally decided upon by the Knesset. ___________________________________________________________________________ Ephraim Silverberg, CS System Group, Phone number: 972-2-6585521 Hebrew University, Jerusalem, Israel. Fax number: 972-2-6585439 WWW: http://www.cs.huji.ac.il/~ephraim E-mail: ephraim(a)cs.huji.ac.il --------------------------------------------------------------------------- # Zone Information Compiler (ZIC) File for the State of Israel (1989-2009) # According to the Office of the Secretary General of the Ministry of # Interior, there is NO set rule for Daylight-Savings/Standard time changes. # Each year they decide anew what havoc to wreak on the country. However, # there is a "supposed" set of rules which is subject to change depending # on the party the Minister of Interior, the size of the coalition # government, the phase of the moon and the direction of the wind. Hence, # changes may need to be made on a semi-annual basis. One thing is entrenched # in law, however: that there must be at least 150 days of daylight savings # time annually. The change to daylight savings time is from midnight IST # to 1 a.m IDT (day of week varies in different years). The change back to # standard time is on a Saturday night from midnight daylight savings time # to 11 p.m. standard time. 1996 is an exception to this rule where the # change back to standard time took place on Sunday night instead of Saturday # night to avoid conflicts with the Jewish New Year. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1989 only - Apr 30 0:00 1:00 D Rule Zion 1989 only - Sep 3 0:00 0:00 S Rule Zion 1990 only - Mar 25 0:00 1:00 D Rule Zion 1990 only - Aug 26 0:00 0:00 S Rule Zion 1991 only - Mar 24 0:00 1:00 D Rule Zion 1991 only - Sep 1 0:00 0:00 S Rule Zion 1992 only - Mar 29 0:00 1:00 D Rule Zion 1992 only - Sep 6 0:00 0:00 S Rule Zion 1993 only - Apr 2 0:00 1:00 D Rule Zion 1993 only - Sep 5 0:00 0:00 S # The dates for 1994-1995 were obtained from Office of the Spokeswoman for the # Ministry of Interior, Jerusalem, Israel. The spokeswoman can be reached by # calling her office directly at 972-2-6701447 or 972-2-6701448. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1994 only - Apr 1 0:00 1:00 D Rule Zion 1994 only - Aug 28 0:00 0:00 S Rule Zion 1995 only - Mar 31 0:00 1:00 D Rule Zion 1995 only - Sep 3 0:00 0:00 S # The dates for 1996 were determined by the Minister of Interior of the # time, Haim Ramon. The dates for 1997 were altered by his successor, # Rabbi Eli Suissa. No changes have been made regarding 1998 as of yet. # # The official announcement for the years 1997 and 1998 can be viewed at: # # ftp://ftp.huji.ac.il/pub/tz/announcements/1997-1998.ps.gz # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1996 only - Mar 15 0:00 1:00 D Rule Zion 1996 only - Sep 16 0:00 0:00 S Rule Zion 1997 only - Mar 23 0:00 1:00 D Rule Zion 1997 only - Sep 14 0:00 0:00 S Rule Zion 1998 only - Mar 20 0:00 1:00 D Rule Zion 1998 only - Oct 18 0:00 0:00 S # These rules are probably wrong, but they are close approximations (usually # within a few weeks): # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1999 only - Apr 11 0:00 1:00 D Rule Zion 1999 only - Sep 5 0:00 0:00 S Rule Zion 2000 only - Apr 30 0:00 1:00 D Rule Zion 2000 only - Sep 24 0:00 0:00 S Rule Zion 2001 only - Apr 15 0:00 1:00 D Rule Zion 2001 only - Sep 9 0:00 0:00 S Rule Zion 2002 only - Apr 7 0:00 1:00 D Rule Zion 2002 only - Sep 1 0:00 0:00 S Rule Zion 2003 only - Apr 27 0:00 1:00 D Rule Zion 2003 only - Sep 21 0:00 0:00 S Rule Zion 2004 only - Apr 18 0:00 1:00 D Rule Zion 2004 only - Sep 12 0:00 0:00 S Rule Zion 2005 only - May 1 0:00 1:00 D Rule Zion 2005 only - Sep 25 0:00 0:00 S Rule Zion 2006 only - Apr 23 0:00 1:00 D Rule Zion 2006 only - Sep 17 0:00 0:00 S Rule Zion 2007 only - Apr 15 0:00 1:00 D Rule Zion 2007 only - Sep 9 0:00 0:00 S Rule Zion 2008 only - Apr 27 0:00 1:00 D Rule Zion 2008 only - Sep 21 0:00 0:00 S Rule Zion 2009 only - Apr 19 0:00 1:00 D Rule Zion 2009 only - Sep 13 0:00 0:00 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Israel 2:00 Zion I%sT

1 0

zic -s bug fixes for year/time extremes (found by code inspection)
by Paul Eggert March 2, 1997

March 2, 1997

I briefly looked for a fix for the problem that Dave Sparks reported today with zic.c, and decided that this will require more zic expertise than I have. However, I did find a couple of related bugs in zic.c by code inspection. First, there are a couple of places in the code that compare for equality to min_year, but values less than min_year are possible if -s is given, so these should be changed to compare for not greater than min_year. (While we're at it, we might as well make max_year symmetric.) Second, the setboundaries function sets min_year and max_year based on GMT, but these values are meant to be bounds for localtime years, so to be safe one must subtract 1 from the GMT min year and add 1 to the GMT max year. This is particularly important with the -s option, since the GMT min year is 1970 but the localtime min year might be 1969. Here is a proposed patch. This patch doesn't fix Sparks's bug, unfortunately. 1997-03-02 Paul Eggert <eggert(a)twinsun.com> * zic.c (setboundaries): Set min_year to be one less than GMT min_year, and max_year to be one greater than GMT max_year, in case local time and GMT disagree about years at time boundaries. (outzone, tadd): Don't assume that min_time and max_time are bounds on time_t values, since -s makes this assumption false. =================================================================== RCS file: RCS/zic.c,v retrieving revision 1997.2.1.1 retrieving revision 1997.2.1.2 diff -c -r1997.2.1.1 -r1997.2.1.2 *** zic.c 1997/02/28 00:22:22 1997.2.1.1 --- zic.c 1997/03/03 03:58:26 1997.2.1.2 *************** *** 647,654 **** max_time <<= TIME_T_BITS_IN_FILE - 1; --max_time; } ! min_year = TM_YEAR_BASE + gmtime(&min_time)->tm_year; ! max_year = TM_YEAR_BASE + gmtime(&max_time)->tm_year; } static int --- 647,654 ---- max_time <<= TIME_T_BITS_IN_FILE - 1; --max_time; } ! min_year = TM_YEAR_BASE + gmtime(&min_time)->tm_year - 1; ! max_year = TM_YEAR_BASE + gmtime(&max_time)->tm_year + 1; } static int *************** *** 1638,1645 **** if (!rp->r_todisstd) offset = oadd(offset, stdoff); jtime = rp->r_temp; ! if (jtime == min_time || ! jtime == max_time) continue; jtime = tadd(jtime, -offset); if (k < 0 || jtime < ktime) { --- 1638,1645 ---- if (!rp->r_todisstd) offset = oadd(offset, stdoff); jtime = rp->r_temp; ! if (jtime <= min_time || ! jtime >= max_time) continue; jtime = tadd(jtime, -offset); if (k < 0 || jtime < ktime) { *************** *** 1978,1986 **** { register time_t t; ! if (t1 == max_time && t2 > 0) return max_time; ! if (t1 == min_time && t2 < 0) return min_time; t = t1 + t2; if ((t2 > 0 && t <= t1) || (t2 < 0 && t >= t1)) { --- 1978,1986 ---- { register time_t t; ! if (t1 >= max_time && t2 > 0) return max_time; ! if (t1 <= min_time && t2 < 0) return min_time; t = t1 + t2; if ((t2 > 0 && t <= t1) || (t2 < 0 && t >= t1)) {

1 0

problem withzic 7.81 (1997a)
by Dave Sparks March 2, 1997

March 2, 1997

I recently downloaded tz{code,data}1997a.tar.gz in order to update our timezone database. Because we will not be using any dates earlier than 1970 I used zic -s to save space. All the timezone information was compiled, but when I tried to install the data into our database four timezones failed the sanity checks. I found that the compiled files for these timezones were each 44 bytes long and contained only zeros. The zones were: Australia/Darwin Africa/Accra Africa/Freetown Africa/Johannesburg (none of which have transitions after 1970). I looked at zic.c and made the following changes: 207% diff zic.c zic.OLD.c 3c3 < static char elsieid[] = "@(#)zic.c 7.81 +DaveS"; --- > static char elsieid[] = "@(#)zic.c 7.81"; 1572a1573 > usestart = i > 0 && (zp - 1)->z_untiltime > min_time; 1576d1576 < usestart = (timecnt == 0 && !useuntil) || (i > 0 && ((zp - 1)->z_untiltime > min_time)); which was partially successful (the Australian timezone was handled, but the African timezones needed modifications which wouldn't have been necessary if the fix had been correct: 208% diff africa africa.OLD 325,326c325 < 0:00 Ghana %s 1942 < 0:00 - WAT --- > 0:00 Ghana %s 561,562c560 < 0:00 SL WA%sT 1962 < 0:00 - WAT --- > 0:00 SL WA%sT 581,582c579 < 2:00 SA SA%sT 1944 < 2:00 - SAT --- > 2:00 SA SA%sT ). After looking more carefully at the timezone data, I realised that what the troublesome timezones had in common wasn't just that there were no transitions after 1970, but also that the last transition was by Rule. Since by then I had compiled data which we could use, I didn't look at zic.c again to try to work out a better fix. Incidentally, the assumption that the first Standard Time offset should be used for times before the first transition doesn't work well for Southern Hemisphere timezones: in many cases Summer Time will be in effect at the earliest time handled. (In case you were wondering why we need to import the timezone data into our own database: the application in question has to handle multiple timezones and is nor written in C or C++.) -- Dave Sparks, Staffordshire, England (posted from my private mailbox to avoid my employer being legally liable, since in English law a disclaimer would be ineffective.)

1 0

Re: ISO 8601 revision
by kuhn＠cs.purdue.edu March 1, 1997

March 1, 1997

Keld J|rn Simonsen wrote on 1997-03-01 22:50 UTC: [How do we get in contact with the ISO 8601 working group?] > I can try to ask the Danish Standards people. Great! > Have you got any suggestions for the "ugly T"? [Anyone interested in this discussion without a copy of ISO 8601, please download and print first <ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/ISO8601.ps.Z> for reference.] I think, a space is the nicest solution as in 1997-03-01 22:50 and it should definitely be explicitely allowed. The current standard gave the author of <http://www.internic.net/internet-drafts/draft-newman-datetime-01.txt> the impression that the "ugly T" is the only comforming way of writing down both date and time, which is the only reason why the new proposed Internet standard date and time format (an ISO 8601 profile) has the "T". Only for applications, where a space is inconvenient (e.g, Unix command line options, where fields are separated by space), the hyphen as used in the corresponding ANSI standard and as shown in the "Chicago Manual of Style" is also quite nice: 1997-02-28-22:50 I do not see, where this overloading of the hyphen would cause problems with the requirement, that a parser must be able to distinguish all formats. If it causes problems with unambiguous parsability, then I wouldn't mind dropping some of the less useful notations from the ensemble. I also find the notation "--MM-DD" awfull for cases where I do not specify the year as it follows from context. It would be much nicer if notations like "-MM-DD" and "-DD" would be part of the collection, as this would allow to use these notations in sentences like "The conference will take place from 1997-08-28 to -31, and the tutorial sessions will run from -08-28 to -09-05." Instead these patterns are currently used for "-YY" and "-YY-MM". I think, using the leading hyphen to indicate the missing century digits was a bad idea. Please note that although ISO 8601 was intended as a standard for data respresentation, it is today quoted in standards for business letter typographical conventions (e.g., DIN 5008-1996). ISO 8601 currently lists numerous incomplete formats which I strongly doubt will ever be used anywhere (e.g., "---DD"). They are in applications like Unix cron, where you want to specify periodic events, much better represented by a more generic extended wildcard notation that allows to specify events like the last Sunday of every month, something ISO 8601 currently does not yet provide. Useful new notations might be 1997-100.5 (noon of the 100th day of 1997) 1997-02-3-7 (the third sunday of February 1997, especially useful with unspecified year or year/month as in *-3-7 or *-02-3-7) These are just a few first ideas for improvement. Once we get in contact with the working group and hear about their plans, we can start working on a detailed proposal. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

1 0