- tz - lists.iana.org

Re: A brief history of (and agenda for) time zone libraries
by ado May 15, 1993

May 15, 1993

Improvidently, a couple of things make buying back the GNU changes at this end difficult. One is not so bad. Since the GNU folks are clearly implementers (in the ANSI sense of the word), they're entitled to use names from the implementers' name space in their code; this means that strictly internal functions can be split into separate source files without polluting the user's name space. It's not clear that this is kosher when the timezone package is distributed independently. But some care in packaging and some creative use of the preprocessor would avoid most challenges here. One is not so tractable. Buying back the GNU code at this point would also involve putting things under the GPL, which I'm loathe to do. --ado

1 0

Re: A brief history of (and agenda for) time zone libraries
by ado May 15, 1993

May 15, 1993

> From roland(a)gnu.ai.mit.edu Sat May 15 18:14:48 1993 > Return-Path: <roland(a)gnu.ai.mit.edu> > Received: from churchy.gnu.ai.mit.edu by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA22472; Sat, 15 May 93 18:14:34 EDT > Received: by churchy.gnu.ai.mit.edu (5.65/4.0) > id <AA21556(a)churchy.gnu.ai.mit.edu>; Sat, 15 May 93 18:14:01 -0400 > Date: Sat, 15 May 93 18:14:01 -0400 > From: roland(a)gnu.ai.mit.edu (Roland McGrath) > Message-Id: <9305152214.AA21556(a)churchy.gnu.ai.mit.edu> > To: eggert(a)twinsun.com > Cc: libc-alpha(a)gnu.ai.mit.edu, tz(a)elsie.nci.nih.gov > Subject: Re: A brief history of (and agenda for) time zone libraries > In-Reply-To: Paul Eggert's message of Sat, 15 May 93 00:08:44 PDT <9305150708.AA18312(a)bi.twinsun.com> > X-Shopping-List: (1) Hot mutant holidays > (2) Apologetic interruptions > (3) Frenetic lesions > > > Olson's 1989 code. > > > > The original timezone code was written by Arthur David Olson. This public > > domain code has a good reputation. Even the Posix standard comes as close as > > a standard can to saying ``This is good stuff -- check it out!''; see Posix > > 1003.1-1990 section B.8.1.1, lines 4195-4201. The most famous publication of > > Olson's code was in comp.sources.unix 18, 111-117 (19 April 1989) -- see > > ftp.uu.net:/usenet/comp.sources.unix/volume18/localtime3/*. > > I wish I had known that this code was being maintained, and where to get it > from, before now. > > > Proposal. > > > > Olson's changes should be propagated into both Linux and the GNU C library. > > Indeed. Linux is not my concern, but I plan to update glibc today. > > > The GNU C library changes fall into two categories: (A) changes to > > Olson's localtime.c, and (B) everything else. Merging (B) is easy, > > almost as easy as merging the Linux timezone code, and I've already > > submitted patches to the GNU C library developers to do this. Merging > > (A) is harder, since the GNU C library has split up localtime.c into lots > > of little pieces. The GNU C library changes generally improve Olson's > > code -- they make the module interfaces cleaner, and the code is easier > > to follow. > > These issues are very important to the GNU project, and to me. > > > Unfortunately, it is now hard to tell how to propagate Olson's > > localtime.c changes and improvements into the GNU C library. The best > > person to do this propagation is the person who split up localtime.c in > > the first place. > > I am that person, and I plan to do the work. > > > Another possibility is for the GNU C library to switch to a version of > > localtime.c that is as close as possible to Olson's latest version; that > > might simplify future maintenance. > > I really don't want to do this. It took me quite a while to untangle the > spaghetti in the first place. This would certainly not simplify > maintenance of the glibc code; it would return it to the obfuscated > spaghetti I started with. Having the code be modular and clean simplifies > maintenance for me. Using code close Olsen's code only simplifies future > merging with Olsen's code. >

1 0

proactive DST discovery?
by ado May 13, 1993

May 13, 1993

If you have insights on the advisability of doing network polling to learn of time changes, or have notions on how it might best be done, I'd appreciate your sharing them with tz(a)elsie.nci.nih.gov. -- Arthur David Olson ado(a)elsie.nci.nih.gov ADO and Elsie are Ampex and Borden trademarks "REM AND STINPY"--found in Bill Gates' startup file

1 0

Daylight savings time
by Monty Solomon May 3, 1993

May 3, 1993

An associate is looking for a source of information regarding the rules for daylight savings time in different countries. He has the North American rules but needs to find a source for Europe, etc. Do other countries observe daylight savings? Thanks. Monty --- # Monty Solomon / PO Box 2486 / Framingham, MA 01701-0405 # monty%roscom(a)think.com

1 0

Re: tzload memory leak?
by Joel.Tornatore＠Eng.Sun.COM April 23, 1993

April 23, 1993

Stephen, I have been out the for the last week (since 4/16, as a matter of fact.....Santa Fe was great!) so if this problem has not been resolved, please let me know. The problem was noticed in Solaris 2.0, and fixed in a patch to SunOS 4.1.3. You will also notice that the tzfile being used is opened and read for each call to tzset(), and the memory was not being freed. I can get you a new libc if necessary. joel > From eubank(a)predict.com Fri Apr 16 16:58 PDT 1993 > To: tz(a)elsie.nci.nih.gov > Subject: tzload memory leak? > > I've been using an application (under SunOS 4.1.3) > which switches time zones frequently. > It has a memory leak which I think I've tracked down to tzload, > which I call via tzset. Since it would hardly be noticeable to anyone > who didn't happen to be using (or abusing) tzset thousands of times, > I wouldn't be surprised if it hadn't been noticed before. On the off > chance that someone out there has encountered it, can you send me > pointers to patches, workarounds, etc.? I can't switch to Solaris yet. > > Here are some details: > I profile this code: > > #include <time.h> > > main() > { > int i; > for (i=0; i<100; i++) { > tzset(); > } > } > > > and find that malloc is called roughly 400 times, while free is called > roughly 300 times. If I increase the number of iterations in the loop > tp 1000, the calls to malloc and free go up by a factor of 10. malloc is > being called from calloc, which is being called from allocall, which is > being called from tzload. It looks to me like tzload allocates 4 things > and only frees 3 of them each time it is called. > > Thanks for any help you can give me. > > Stephen Eubank > eubank(a)predict.com >

1 0

Re: tzload memory leak?
by guy＠auspex.com April 17, 1993

April 17, 1993

> It has a memory leak which I think I've tracked down to tzload, > which I call via tzset. The data that's mallocated by the time zone stuff in SunOS 4.x is: the array of transition times; the array of information about the State Of The Time Zone after a given transition time (offset from GMT, DST or not, index into the list of time zone abbreviation strings, etc.); the array of time zone types (indices into the array of information about the State Of The Time Zone after a given transition time); the array of "char"s that contains the aforementioned abbreviation strings. Applications can't get a pointer to any of the first three items, so they can be freed whenever "tzset()" is called. However, it appears that the array containing abbreviation strings isn't freed because, according to the comment, it "might have other references to it", presumably obtained by using the "tzname[]" array (in the SV environment) or by using the "tm_zone" member of "struct tm". Now, from the way I read POSIX 1003.1, it neither commits to pointers fetched from "tzname[]" remaining valid after a call to "tzset()", nor explicitly claims that one should *not* assume they'll still point somewhere valid. The "ctime" manual page *does*, however, explicitly note that calls to "tzset()" or "tzsetwall()" overwrite the array to which the "tm_zone" field points. So I'm not sure what provoked somebody to make "tzset()" *not* free up the abbreviation-strings array - which is kind of annoying, given that I'd be willing to bet I'm the person who made it not do so, and seem to remember having done so because some stupid piece of software broke when it *did* free it.... Unfortunately, the pointer to that array is in a structure pointed to by a static pointer. However, *if* you can call "localtime()" on a time that's known to be in a time zone that corresponds to the first abbreviation in the file - possibly easier said than done, although you might try passing it first a pointer to a value of -1, and then a pointer to a value of "-1 plus half a year", and then, for each of the times, if "localtime()" doesn't return a null pointer, save the "tm_zone" values and, if both of them are non-NULL, see which one is lower - you can try doing a "free()" on the "tm_zone" value for that time zone. This is a somewhat disgusting hack, but, well, that's life....

1 0

tzload memory leak?
by eubank＠predict.com April 16, 1993

April 16, 1993

I've been using an application (under SunOS 4.1.3) which switches time zones frequently. It has a memory leak which I think I've tracked down to tzload, which I call via tzset. Since it would hardly be noticeable to anyone who didn't happen to be using (or abusing) tzset thousands of times, I wouldn't be surprised if it hadn't been noticed before. On the off chance that someone out there has encountered it, can you send me pointers to patches, workarounds, etc.? I can't switch to Solaris yet. Here are some details: I profile this code: #include <time.h> main() { int i; for (i=0; i<100; i++) { tzset(); } } and find that malloc is called roughly 400 times, while free is called roughly 300 times. If I increase the number of iterations in the loop tp 1000, the calls to malloc and free go up by a factor of 10. malloc is being called from calloc, which is being called from allocall, which is being called from tzload. It looks to me like tzload allocates 4 things and only frees 3 of them each time it is called. Thanks for any help you can give me. Stephen Eubank eubank(a)predict.com

1 0

FYA
by guy＠auspex.com April 6, 1993

April 6, 1993

Yes, but whose code is it using? :-) From: knauer(a)cs.uiuc.edu (Rob Knauerhase) Newsgroups: rec.humor.funny Subject: Daylight Savings Keywords: topical, smirk Message-ID: <S530.605b(a)looking.on.ca> Date: 6 Apr 93 07:20:02 GMT Organization: Department of Computer Science, Univ. of Illinois @ Urbana My mother didn't know just how smart her new VCR was until she got up this morning and noticed it was flashing: 1:00 1:00 1:00 1:00 1:00... Rob -- Rob Knauerhase, University of Illinois @ Urbana, Dept. of Computer Science "See, when the GOVERNMENT spends money, it creates jobs; whereas when the money is left in the hands of TAXPAYERS, God only knows what they do with it. Bake it into pies, probably. Anything to avoid creating jobs." -- Dave Barry -- Selected by Maddi Hausmann. MAIL your joke (jokes ONLY) to funny(a)clarinet.com. Attribute the joke's source if at all possible. A Daemon will auto-reply. Remember: Only ONE joke per submission. Extra jokes may be rejected.

1 0

Re: CORRECTION: April 18 in CM of OW3
by guy＠auspex.com March 29, 1993

March 29, 1993

> As a matter of fact, this year, summer time in Israel starts at 3-Apr-93 > till 4-Sep-93. Every year the dates of summer time are decided at that > year and cannot be anticipated. I.e., either Ephraim Silverberg, who contributed the most-recently-seen rules for Israel, as seen in "/usr/share/lib/zoneinfo/asia" in SunOS 4.x and 5.x systems and elsewhere: # From Ephraim Silverberg (April 18, 1989): # Prior to 1989, the rules concerning Daylight Savings Time changed every # year; as information, regarding exact times and dates during this period, # is not readily available at the present time, the rules commence starting # with the year 1989. # From 1989 onwards the rules are as follows: # # 1. Daylight Savings Time commences midnight of the first Saturday night # following the seven-day festival of Pesach (Passover). The transition # is from midnight Israel Standard Time to 1 a.m. Israel Daylight Savings # time. As the Pesach festival is dependent on the Lunar calendar (the # first day is always on the 15th day of the month of Nisan), the rule # changes every year on the Gregorian calendar. # # 2. Standard Time is reinstated on the Saturday night whereupon Jews # following the Ashkenazi (European) rite begin to recite the Selichot # (forgiveness) prayers prior to the Jewish Lunar New Year. The transition # is from midnight Israel Daylight Savings time to 11 p.m. Israel Standard # Time. The law (according to the Ashkenazi custom) concerning the # commencement of the Selichot prayers is described in chapter 128, section # 5 of the "Code of Jewish Law," by Rabbi Shlomo Ganzfried (translated by # Hyman E. Goldin): # # Beginning with the Sunday [**] before Rosh Hashanah [***], # we rise early for the service of Selichot (supplications for # forgiveness). If Rosh Hashanah occurs on Monday or Tuesday, we # begin saying the Selichot from the Sunday of the preceding week. # # This, too, varies from year to year on the Gregorian calendar and, thus, # two explicit timezone rules are required for each Gregorian year. # # [**] actually Saturday night as the Jewish day commences at nightfall. # [***] the Jewish Lunar New Year. was mistaken, or, after he sent that information out, the government went back to changing the rules every year? (Please "Cc:" "tz(a)elsie.nci.nih.gov" on any responses.)

1 0

Re: CORRECTION: April 18 in CM of OW3
by guy＠auspex.com March 29, 1993

March 29, 1993

>A week ago I asked: > >>Calendar Manager on Open window 3 has a bug. April 18 cannot be scheduled. >>Try it on your machine and return to me if you find a way to overcome it. > >Thank you all for your answers in which you said that such a problem >doe's not exist on your machine. Well, the problem found in file: > >/usr/share/lib/zoneinfo/asia > >April 18, 1993 was one line in that file which indicates the day of >summer time in Israel. > >Rule Zion 1993 only - Apr 18 00:00 1:00 D > >This line was fixed to: > >Rule Zion 1993 only - Apr 1 23:00 1:00 D > > >and after running 'zic asia', the problem disappear. > >Thanks > >-- > /\/\/\ E-mail: joel(a)mcil.comm.mot.com [ Motorola Communications Israel ] >/ Joel \ X.400 CJN003 [ Fixed & Data Products Division ] >\ Nahum/ Phone: +972 (3) 565-8479 [ 3 Kremenetski Street ] > \____/ Fax: +972 (3) 565-8356 [ 61 250 Tel-Aviv, ISRAEL ] Are you saying that Summer Time begins on April 1, not April 18, this year? If so, it'd cause problems with more than *just* the Calendar Manager, as the compiled time-zone files are used throughout the system. Are there any other errors in the rules for Israel in the "asia" file? We (the Timezone Cabal) would like to have the data in all the files be as correct as possible, so please send us any corrections you have.... (Timezone Caballeros: Should I post a followup and/or a note to "comp.sys.sun.admin" and possibly also "comp.unix.bsd" and "comp.unix.sys5.r4", requesting that *all* fixes to the timezone files be sent to "tz(a)elsie.nci.nih.gov"?)

1 0