- tz - lists.iana.org

Israel Timezone -- Dates for 1999
by Ephraim Silverberg Dec. 28, 1998

Dec. 28, 1998

Here are the dates for Israel for 1999. The main changes are starting in 1999, the Friday morning changeover to DST will take place at 2 a.m. instead of midnight and the change back will also be on a Friday morning at 2 a.m. instead of Saturday night at midnight. The following are context diffs for the file 'asia' extracted from ftp://elsie.nci.nih.gov/pub/tzdata1998i.tar.gz -----------------------------Begin Context Diff------------------------------ *** asia Thu Sep 24 16:46:09 1998 --- asia.new Mon Dec 28 12:26:31 1998 *************** *** 509,530 **** Rule Zion 1988 only - Sep 3 0:00 0 S # From Ephraim Silverberg <ephraim(a)cs.huji.ac.il> ! # (1997-03-04 and 1998-03-16): # 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. Ever since 1993, the change to daylight savings time is ! # on a Thursday night from midnight IST to 1 a.m IDT. 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 --- 509,529 ---- Rule Zion 1988 only - Sep 3 0:00 0 S # From Ephraim Silverberg <ephraim(a)cs.huji.ac.il> ! # (1997-03-04, 1998-03-16 and 1998-12-28): # According to the Office of the Secretary General of the Ministry of # Interior, there is NO set rule for Daylight-Savings/Standard time changes. ! # One thing is entrenched in law, however: that there must be at least 150 ! # days of daylight savings time annually. From 1993-1998, the change to ! # daylight savings time was on a Friday morning from midnight IST to ! # 1 a.m IDT; up until 1998, the change back to standard time was 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. Starting in 1999, the change to ! # daylight savings time will still be on a Friday morning but from ! # 2 a.m. IST to 3 a.m. IDT; furthermore, the change back to standard time ! # will now also be on a Friday morning from 2 a.m. IDT to 1 a.m. IST. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1989 only - Apr 30 0:00 1:00 D *************** *** 570,588 **** Rule Zion 1997 only - Sep 14 0:00 0 S Rule Zion 1998 only - Mar 20 0:00 1:00 D Rule Zion 1998 only - Sep 6 0:00 0 S ! # From Member of Knesset Avraham Poraz, as quoted in Ha'aretz (1998-09-02): ! # [The 1998-09-06 transition is to] serve the interests of a small minority ! # of ultra-Orthodox Sephardic Jews who, during the [Hebrew] month of Elul, ! # recite Slihot penitential prayers in the early morning hours ! # and thus find daylight time inconvenient. # From Paul Eggert (1998-01-12): ! # Here are guesses for rules after 1998. # They are probably wrong, but they are more likely than no DST at all. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! Rule Zion 1999 max - Mar Fri>=15 0:00 1:00 D ! Rule Zion 1999 max - Sep Sun>=1 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Jerusalem 2:20:56 - LMT 1880 --- 569,589 ---- Rule Zion 1997 only - Sep 14 0:00 0 S Rule Zion 1998 only - Mar 20 0:00 1:00 D Rule Zion 1998 only - Sep 6 0:00 0 S + Rule Zion 1999 only - Apr 2 2:00 1:00 D + Rule Zion 1999 only - Sep 3 2:00 0 S ! # Due to imminent elections in 1999, there are no dates for the year 2000 ! # and beyond. There was a move to legislate the DST rules in Israel, but ! # due to the government's fall, it most likely won't be brought to the Knesset ! # for first reading before the elections and will probably be altered by the ! # newly elected government. # From Paul Eggert (1998-01-12): ! # Here are guesses for rules after 1999. # They are probably wrong, but they are more likely than no DST at all. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! Rule Zion 2000 max - Mar Fri>=15 2:00 1:00 D ! Rule Zion 2000 max - Sep Fri>=1 2:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Jerusalem 2:20:56 - LMT 1880 ------------------------------End Context Diff------------------------------- ___________________________________________________________________________ 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

1 0

RE: Solaris mktime with multiple timezones
by Olson, Arthur David (NCI) Nov. 23, 1998

Nov. 23, 1998

I compiled the small program (bugtest.c) mentioned in the letter below using the latest elsie.nci.nih.gov source; the program ran okay. As Scott mentions, folks on the mailing list probably do need to be aware of the bug. --ado From: Scott Harrington [SMTP:seh4@ix.netcom.com] Sent: Friday, November 06, 1998 1:16 PM Subject: BUG: Solaris mktime with multiple timezones I have posted the attached message to comp.unix.solaris, so replies should probably be posted there. I wanted to notify this mailing list since the bug affects those who use multiple time zones in their programs... I have uncovered a bug in the mktime() routine found in libc.so.1 and libc.a on my SunOS 5.5.1 Generic_103640-12 sun4u sparc SUNW,Ultra-2 machine: -rw-r--r-- 1 bin bin 1155756 Jun 23 1997 /usr/lib/libc.a -rwxr-xr-x 1 bin bin 664760 Jun 23 1997 /usr/lib/libc.so.1 I have attached a small program which should determine if your system has the bug or not.

1 0

FW: symlinks in zic
by Olson, Arthur David (NCI) Nov. 17, 1998

Nov. 17, 1998

-----Original Message----- From: Mani Varadarajan [SMTP:mani@be.com] Sent: Monday, November 16, 1998 9:04 PM To: eggert(a)twinsun.com; tz(a)elsie.nci.nih.gov Subject: symlinks in zic Dear Time Zone experts, I incorporated your timezone database into the BeOS last year. The BeOS file system does not support hard links, so I had to implement symbolic link support myself. Judging from the latest version of tzcode, which I just stumbled upon today, I notice that you have done the same. I suggest a few changes to your implementation, detailed in the attached diff. The problem with how it is right now is that if zic is invoked as follows: zic -d foodir <rules files> where foodir is a relative and not an absolute path, the symbolic links in the timezone database point to bogus places. (We use relative paths in our build environment at Be during our daily builds of the BeOS.) My proposed changes fix this problem. We have used my modified version of zic for over a year now in production without any problems. Please let me know what you think of the changes. I am not on this list so please keep me on the CC list. Thanks, Mani *** zic.c.old Mon Nov 16 17:48:18 1998 --- zic.c Mon Nov 16 16:47:55 1998 *************** *** 605,616 **** if (mkdirs(toname) != 0) (void) exit(EXIT_FAILURE); result = link(fromname, toname); #if (HAVE_SYMLINK - 0) if (result != 0) { ! result = symlink(fromname, toname); if (result == 0) warning(_("hard link failed, symbolic link used")); } #endif if (result != 0) { --- 605,624 ---- if (mkdirs(toname) != 0) (void) exit(EXIT_FAILURE); + result = link(fromname, toname); #if (HAVE_SYMLINK - 0) if (result != 0) { ! char *s = (char *) tofile; ! register char * symlinkcontents = NULL; ! while ((s = strchr(s+1, '/')) != NULL) ! symlinkcontents = ecatalloc(symlinkcontents, "../"); ! symlinkcontents = ecatalloc(symlinkcontents, fromfile); ! ! result = symlink(symlinkcontents, toname); if (result == 0) warning(_("hard link failed, symbolic link used")); + ifree(symlinkcontents); } #endif if (result != 0) {

1 0

symlinks in zic
by Mani Varadarajan Nov. 17, 1998

Nov. 17, 1998

Dear Time Zone experts, I incorporated your timezone database into the BeOS last year. The BeOS file system does not support hard links, so I had to implement symbolic link support myself. Judging from the latest version of tzcode, which I just stumbled upon today, I notice that you have done the same. I suggest a few changes to your implementation, detailed in the attached diff. The problem with how it is right now is that if zic is invoked as follows: zic -d foodir <rules files> where foodir is a relative and not an absolute path, the symbolic links in the timezone database point to bogus places. (We use relative paths in our build environment at Be during our daily builds of the BeOS.) My proposed changes fix this problem. We have used my modified version of zic for over a year now in production without any problems. Please let me know what you think of the changes. I am not on this list so please keep me on the CC list. Thanks, Mani *** zic.c.old Mon Nov 16 17:48:18 1998 --- zic.c Mon Nov 16 16:47:55 1998 *************** *** 605,616 **** if (mkdirs(toname) != 0) (void) exit(EXIT_FAILURE); result = link(fromname, toname); #if (HAVE_SYMLINK - 0) if (result != 0) { ! result = symlink(fromname, toname); if (result == 0) warning(_("hard link failed, symbolic link used")); } #endif if (result != 0) { --- 605,624 ---- if (mkdirs(toname) != 0) (void) exit(EXIT_FAILURE); + result = link(fromname, toname); #if (HAVE_SYMLINK - 0) if (result != 0) { ! char *s = (char *) tofile; ! register char * symlinkcontents = NULL; ! while ((s = strchr(s+1, '/')) != NULL) ! symlinkcontents = ecatalloc(symlinkcontents, "../"); ! symlinkcontents = ecatalloc(symlinkcontents, fromfile); ! ! result = symlink(symlinkcontents, toname); if (result == 0) warning(_("hard link failed, symbolic link used")); + ifree(symlinkcontents); } #endif if (result != 0) {

1 0

FW: Asia/Ishigaki?
by Olson, Arthur David (NCI) Nov. 16, 1998

Nov. 16, 1998

-----Original Message----- From: Hideyuki Suzuki [SMTP:hideyuki@sat.t.u-tokyo.ac.jp] Sent: Monday, November 09, 1998 6:50 AM To: tz(a)elsie.nci.nih.gov Subject: Re: Asia/Ishigaki? I also examined other data concerning Japan in tzdata1998i. The patch at the bottom of this mail fixes the following points. - Only one timezone JST is used everywhere in Japan. - In tzdata1998i, the location of 'Tokyo' (+3542+13946) seems to be around the University of Tokyo. However, 'Tokyo' usually stands for the former location of Tokyo Astronomical Observatory: E 139 44' 40".90 (9h 18m 58s.727), N 35 39' 16".0. This data is from 'Rika Nenpyou (Chronological Scientific Tables) 1996' edited by National Astronomical Observatory of Japan. - JST (Japan Standard Time) has been used since Jan. 1, 1888 0:00AM (JST). The law is enacted on July 7, 1886. I couldn't understand the comment 'There is no information for Marcus.' Does anyone know what 'Marcus' is? -- hideyuki diff -u tzdata1998i/asia tzdata/asia --- tzdata1998i/asia Thu Sep 24 23:46:09 1998 +++ tzdata/asia Mon Nov 9 20:12:24 1998 @@ -610,12 +610,9 @@ # We go with Shanks and omit daylight saving in those years for Asia/Tokyo. # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Asia/Tokyo 9:19:04 - LMT 1896 +Zone Asia/Tokyo 9:18:59 - LMT 1887 9:00 - JST -Zone Asia/Ishigaki 8:16:36 - LMT 1896 - 8:00 - CST # There is no information for Marcus. -# Other Japanese possessions are probably like Asia/Tokyo. # Jordan # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S diff -u tzdata1998i/zone.tab tzdata/zone.tab --- tzdata1998i/zone.tab Thu Sep 24 23:46:11 1998 +++ tzdata/zone.tab Mon Nov 9 19:25:10 1998 @@ -188,8 +188,7 @@ IT +4154+01229 Europe/Rome JM +1800-07648 America/Jamaica JO +3157+03556 Asia/Amman -JP +3542+13946 Asia/Tokyo most locations -JP +2420+12409 Asia/Ishigaki south Ryukyu Islands +JP +3539+13944 Asia/Tokyo KE -0117+03649 Africa/Nairobi KG +4254+07436 Asia/Bishkek KH +1133+10455 Asia/Phnom_Penh

3 3

FW: Asia/Ishigaki?
by gwil＠mindspring.com Nov. 10, 1998

Nov. 10, 1998

>From: Hideyuki Suzuki [SMTP:hideyuki@sat.t.u-tokyo.ac.jp] > [...] >I couldn't understand the comment 'There is no information for Marcus.' >Does anyone know what 'Marcus' is? Marcus Island is the name used by Americans for Minami-Tori-shima. It's located at about 24 deg. 18 min. N., 153 deg. 58 min. E., which I think makes it the easternmost, as well as one of the southernmost, of the Japanese islands. It was administered by the U.S. military from the end of World War II to 1968. This background should help to explain why it's referred to by its American name, and why it might be expected to lie in a different time zone. -- Gwillim Law

1 0

FW: Asia/Ishigaki?
by Olson, Arthur David (NCI) Nov. 9, 1998

Nov. 9, 1998

-----Original Message----- From: Hideyuki Suzuki [SMTP:hideyuki@sat.t.u-tokyo.ac.jp] Sent: Saturday, November 07, 1998 11:54 AM To: tz(a)elsie.nci.nih.gov Subject: Asia/Ishigaki? In tzdata1998i.tar.gz, I found that two timezones are defined for Japan. This is somewhat strange to me, because only JST (+0900) is used everywhere in Japan including Ishigaki island. I want to suggest that Asia/Ishigaki (CST, +0800) zone should be removed. However, you may wonder why it was added to the database, and in tzarchive I found the following comment: Date: Tue, 3 Sep 1996 17:14:22 -0700 From: Paul Eggert <eggert(a)twinsun.com> Subject: proposed patch for selecting TZ, MET->CST, Sri Lanka, Antarctica,... > Asia/Ishigaki - uncomment it, since it seems to be right I don't know whether the zone was added at this time, but I suspect that it was added because of an ambiguous reason. So, I believe that it should be removed. I'm not on the tz list, so please leave my address in Cc: line when you reply. Thanks. -- hideyuki

1 0

Asia/Ishigaki?
by Hideyuki Suzuki Nov. 9, 1998

Nov. 9, 1998

In tzdata1998i.tar.gz, I found that two timezones are defined for Japan. This is somewhat strange to me, because only JST (+0900) is used everywhere in Japan including Ishigaki island. I want to suggest that Asia/Ishigaki (CST, +0800) zone should be removed. However, you may wonder why it was added to the database, and in tzarchive I found the following comment: Date: Tue, 3 Sep 1996 17:14:22 -0700 From: Paul Eggert <eggert(a)twinsun.com> Subject: proposed patch for selecting TZ, MET->CST, Sri Lanka, Antarctica,... > Asia/Ishigaki - uncomment it, since it seems to be right I don't know whether the zone was added at this time, but I suspect that it was added because of an ambiguous reason. So, I believe that it should be removed. I'm not on the tz list, so please leave my address in Cc: line when you reply. Thanks. -- hideyuki

1 1

BUG: Solaris mktime with multiple timezones
by Scott Harrington Nov. 6, 1998

Nov. 6, 1998

I have posted the attached message to comp.unix.solaris, so replies should probably be posted there. I wanted to notify this mailing list since the bug affects those who use multiple time zones in their programs. -------- Original Message -------- Subject: BUG: Solaris mktime with multiple timezones Date: Fri, 06 Nov 1998 18:09:17 +0000 From: Scott Harrington <seh4(a)ix.netcom.com> Newsgroups: comp.unix.solaris I have uncovered a bug in the mktime() routine found in libc.so.1 and libc.a on my SunOS 5.5.1 Generic_103640-12 sun4u sparc SUNW,Ultra-2 machine: -rw-r--r-- 1 bin bin 1155756 Jun 23 1997 /usr/lib/libc.a -rwxr-xr-x 1 bin bin 664760 Jun 23 1997 /usr/lib/libc.so.1 The error is that mktime() returns WRONG values when you're switching between multiple time zones in a single program. I have attached a small program which should determine if your system has the bug or not. I make a mktime call in GB timezone, and then in GMT timezone. The second lookup returns incorrect values. If you have the bug, your output will be: TZ=GB 892162800 0 0 0 10 3 98 5 99 1 should be TZ=GB 892162800 0 0 0 10 3 98 5 99 1 TZ=GMT 892162800 0 0 23 9 3 98 4 98 0 should be TZ=GMT 892166400 0 0 0 10 3 98 5 99 0 On systems which implement mktime correctly, the output will be: TZ=GB 892162800 0 0 0 10 3 98 5 99 1 should be TZ=GB 892162800 0 0 0 10 3 98 5 99 1 TZ=GMT 892166400 0 0 0 10 3 98 5 99 0 should be TZ=GMT 892166400 0 0 0 10 3 98 5 99 0 I am curious to find out on which systems this bug exists. (2.6? /opt/SUNWspro/lib/libc.so.1?) The public Sunsolve patch list apropos 'libc' only led me to patch 103612-46 (I already had 103612-30) and applying this patch did not fix the problem. I have a crude LD_PRELOAD workaround (using the implementation of mktime from GNU glibc-2.0.7) for existing executables, if anyone is interested let me know and I will mail it or post it to this newsgroup. #include <time.h> #include <stdio.h> #include <stdlib.h> int main(int argc, char **argv) { time_t t; { struct tm tmBuf = {0, 0, 0, 10, 3, 98, 0, 0, -1}; putenv("TZ=GB"); t = mktime(&tmBuf); printf("TZ=GB %ld %d %d %d %d %d %d %d %d %d", t, tmBuf.tm_sec, tmBuf.tm_min, tmBuf.tm_hour, tmBuf.tm_mday, tmBuf.tm_mon, tmBuf.tm_year, tmBuf.tm_wday, tmBuf.tm_yday, tmBuf.tm_isdst); printf(" should be\n"); printf("TZ=GB 892162800 0 0 0 10 3 98 5 99 1\n"); } printf("\n"); { struct tm tmBuf = {0, 0, 0, 10, 3, 98, 0, 0, -1}; putenv("TZ=GMT"); t = mktime(&tmBuf); printf("TZ=GMT %ld %d %d %d %d %d %d %d %d %d", t, tmBuf.tm_sec, tmBuf.tm_min, tmBuf.tm_hour, tmBuf.tm_mday, tmBuf.tm_mon, tmBuf.tm_year, tmBuf.tm_wday, tmBuf.tm_yday, tmBuf.tm_isdst); printf(" should be\n"); printf("TZ=GMT 892166400 0 0 0 10 3 98 5 99 0\n"); } exit(0); }

1 0

Re: new time conversion interface
by Nathan Myers Nov. 5, 1998

Nov. 5, 1998

Paul Hill wrote: > Nathan Myers wrote: > > > We're dealing with _humans_, here. It's a reasonable goal to try to > > increase the reliability of time entries by noting likely errors. > > ... > > A note that the time changed recently is *extremely* helpful when > > getting confirmation of a time entry, but most programmers are not > > equipped or inclined to root about in a transition database, > > Why would a programmer want to? To minimize mistakes. Any relevant information the system has that the user doesn't is a lost opportunity. People are not (uniformly) stupid, and can respond usefully to a notification that an entered time is dubious. Likewise, a logged timestamp annotated with reasons to doubt it may be more useful than a bare timestamp. The conversion function has discovered the information, the calling program is equipped to decide if it's useful. > The programmer asked to please > convert the fields into a timestamp given the TZ provided. I don't > see how going to look for other transition rules has anything to > do with it. There is still a list of possible interpretations > given just one possible fully accurate TZ definition. Current conversion functions don't report a list of possible interpretations, they report just one. That's what I'd like to fix in this interface. > Going looking > in a transition DB only provides more entries for the list returned > (An additional entry might capture a possible alternate based on > the possibility that the programmer really did not pass the library > the right TZ, because the library code can see that the given rules > did not apply on the date provided in the time struct.) The point is that the conversion function has just looked up all the relevant entries. It can discard any additional information it has gathered, or report it. The caller is equipped to choose which of the additional information is useful, but only if it's reported. > > I agree that the two examples are too similar. Originally I had > > #0 as the canonical "certain" time, and then realized that (as > > you noted) that condition is rare. At some point the likelihood > > of an error due to a transition becomes smaller than that of a > > simple typo, which can only be determined empirically. > > So how are you going to put that fuzzy set in the library code so > that sometimes you can return a "doubtful subsitution" and sometimes > you can return a "possible unofficial time"? Maybe instead of a "doubtful/possible" flag it just reports how long before the reported time the last transition occurred, and what the conversion would be if that one was missed. > > > Speaking of ambiguity, could you explain what your are really trying > > > to capture in #1 and #2, because your descriptions are of the same > > > circumstance. > > > > Er, that's a typo. ... > > > > The intended entry for #2 was 03:30. This is a valid "official" > > time, unlike 02:30. However, it is very likely to be wrong. > > But that makes the #2 entry jibberish, if I rewrite it as [gibberish] > Maybe it should be: > 2. Spring ambiguity, enter 03:30, but that is so close to the > change time it is suspicious. > > It would seem you could do the discussion of favor and repost a > complete list of possible combinations and what kind of rules you > are going to use to put your tags on all of the different > interpretations. That might not be the best description of the goal. The goal is a way for the conversion function to report the circumstances of the conversion in a form that is easily interpreted for different purposes. In my posting I was too specific about what are still unresolved design issues. > > Cases that are identical as far as the program is concerned > > (time is an hour off because of a clock not reset) are quite > > different in how the user experiences them. > > "identical as far as the program is concerned", but you are trying > to return two different values from the "alternative" time. > ... > One has to ask: since you have 16 possible return flag combinations, > could you please explain why only 5 of them are covered in your > list (and I see only 2), and what is right or wrong about the other > 11, i.e. "doubtful ... unofficial" etc. If you only have 5, just > have one enum that lists them and not imply states that don't exist. It may be that one enum with five values, or with four values and a field for when the last time change happened, would be appropriate. Again, you have identified a danger of being too specific. What I posted was an (unfortunately confusing) example meant to lend some concreteness to the discussion. Can we agree that it's useful for the conversion function to report (also) the circumstances of the conversion? Then we can proceed to explore how to report those circumstances. Nathan Myers ncm(a)cantrip.org

1 0