- tz - lists.iana.org

good news; missing person
by ado April 12, 1987

April 12, 1987

The new time zone stuff and System V time zone stuff behave differently if there's no TZ environment variable. The good news is that this difference is irrelevant, since there's "always" (supposed to be) a TZ environment variable in System V systems. This also means, of course, that other time zone handling schemes are free to do whatever they want if TZ is absent. (Now if I can just remember this until the next time it comes up. . .) Missing person department: mail can no longer be sent to greg(a)nosc.arpa, who's been on the list until now. If anyone has a fully-domainized address for greg, let me know. --ado

1 0

tzsetwall() vs. doing explicit things
by seismo!hadron!jsdy April 12, 1987

April 12, 1987

Quick question: doesn't a new question warrant a new Subject: line? We've been going quite a while on these two ... I think that one should use a function specially provided (tzsetwall()) to set the time to "wall clock" time. This could unsetenv("TZ"), or read the "localtime" file for appropriate values of "TZ", or whatever. I like the latter approach, myself ... probably requires unsetenv() and setenv() to do right, though. The point is that we should hide as much of the messy detail as possible inside the time library/module. Joe Yao jsdy(a)hadron.COM (not yet domainised) hadron!jsdy(a){seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM} {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

1 0

Re: extending the time range
by seismo!hadron!jsdy April 12, 1987

April 12, 1987

Agreed, there should probably be a new data type (although mark's suggestion tickles my fancy, as a short-range hack). But 64 bits is still limiting. I like an earlier suggestion to use a text- string or a coded decimal string date. Joe Yao jsdy(a)hadron.COM (not yet domainised) hadron!jsdy(a){seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM} {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

1 0

TZ changes
by seismo!sun!gorodish!guy April 10, 1987

April 10, 1987

In my experience, the "timezone" variable on USG systems is always positive -- that is, application code subtracts its value from the current time, rather than adding it. I have supplied a diff for localtime.c so that if USG_COMPAT is defined, the value of the global "timezone" variable is forced positive. This is based on observations of Plexus System 3, Xenix System 3, and Xenix System 5. I don't know how USG would treat negative offsets from GMT. Observations presumably not made in Europe. You are correct in that the sign of the "timezone" variable should be positive for time zones such as those in the Western Hemisphere; however, it is not correct to force the offset to be positive, as there are places where the offset simply *isn't* positive (using the UNIX sign conventions). The correct fix is 182c185 < timezone = s.ttis[0].tt_gmtoff; --- > timezone = -s.ttis[0].tt_gmtoff; 197c200 < timezone = ttisp->tt_gmtoff; --- > timezone = -ttisp->tt_gmtoff; or something like that.

1 0

None
by Robert Elz April 10, 1987

April 10, 1987

Date: Fri, 10 Apr 87 11:52:31 cst From: ihnp4!infoswx!lan000!rfw Message-ID: <8704101752.AA13197(a)infoswx.UUCP> In my experience, the "timezone" variable on USG systems is always positive -- that is, application code subtracts its value from the current time, rather than adding it. This indicates a real bug, though your precise wording is incorrect. The real problem is that timezone is the opposite sign than it ought to be, and the fix is simply to negate it (always .. not just when it would otherwise be negative), in zones east of Greenwich, "timezone" should in fact be negative (and the application still subtracts its value from the current time). Its probably indicative of just how little used this variable is incidentally, that this bug wasn't noticed before! If there was ever good evidence to simply kill "timezone" then I think this is it! I would also be interested in exactly what application that you have that uses this variable. Does it use it correctly? Simply subtracting it from a time isn't correct, as that won't work in daylight saving times. About all I can think of is that you look at tm_isdst and if that's set compensate by 1 hour (assuming that it is, always, one hour). I don't think the other fixes are appropriate at the minute, but this one will get into a patch posted to mod.sources. Robert Elz

1 0

Re: Reason for DST change in US
by seismo!nbires!vianet!devine April 8, 1987

April 8, 1987

>From uucp Wed Apr 8 17:00 EST 1987 >From hadron!jsdy Wed Apr 8 07:37:44 1987 remote from nbires Received: from hadron.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA00984; Wed, 8 Apr 87 10:21:59 EDT Received: by hadron.UUCP (4.12/4.7) id AA02725; Wed, 8 Apr 87 10:17:34 est Date: Wed, 8 Apr 87 10:17:34 est From: hadron!jsdy (Joseph S. D. Yao) Message-Id: <8704081517.AA02725(a)hadron.UUCP> To: nbires!vianet!devine Subject: Re: Reason for DST change in US Cc: elsie!tz Joe Yao writes: > (*sigh*) That may have been a contribution (nopunintended) to DST > being finally implemented. I know the Farmers' lobby was agin' it. > However, Ben Franklin thought up the idea during one of his ... > ummm ... voyages ("junkets" is not used in this area ;-)) to Paris. > That was a few years before Clorox and Charcoal Briquettes. > > I do notice, however, that your article did not claim that it was > solely done at the behest of Halstead, nor solely for his benefit. > I seem to vaguely recall some other considerations. And that was > definitely not the consideration for its adoption during the War(s), > which was probably what inspired Halstead et al. later on. You misunderstand. I said that the Halstead proposal was just for moving the start of US's DST from the last Sunday in April to the first. I did not write that Halstead was responsible for the invention of the DST idea. His lobbying of Congress occurred about 4 years ago. Here's a thumbnail sketch of how DST came to be: Benjamin Franklin's suggestion for DST was during his tenure as the US ambassador to France (not some junket). His suggestion was ignored. Probably because of the confusion that would have been added to the non-standard timezones then used. However, the true inspiration for DST might have come from a more modern source. An Englishman, William Willet, published a pamphlet in 1907 that called for a seasonal variation in much the same way that Franklin had proposed over a hundred years before him. The first real use of DST came about because of the demands of war. Germany used it during WW I to save electricity. The UK soon followed and many countries did likewise. Most called it "summer time" or "war time". After WW I was over, DST was not observed uniformly across the US because Congress stopped the national observance but many localities kept it anyway. Bob Devine

1 0

Re: Reason for DST change in US
by seismo!hadron!jsdy April 8, 1987

April 8, 1987

> Cost for this recreation windfall was about $50,000 in lobbying costs. (*sigh*) That may have been a contribution (nopunintended) to DST being finally implemented. I know the Farmers' lobby was agin' it. However, Ben Franklin thought up the idea during one of his ... ummm ... voyages ("junkets" is not used in this area ;-)) to Paris. That was a few years before Clorox and Charcoal Briquettes. I do notice, however, that your article did not claim that it was solely done at the behest of Halstead, nor solely for his benefit. I seem to vaguely recall some other considerations. And that was definitely not the consideration for its adoption during the War(s), which was probably what inspired Halstead et al. later on. Joe Yao jsdy(a)hadron.COM (not yet domainised) hadron!jsdy(a){seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM} {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

1 0

Reason for DST change in US
by seismo!nbires!vianet!devine April 7, 1987

April 7, 1987

The Associated Press ran a short story this past week on how the change in daylight saving time came to be. The following is not a verbatim transcription but the parts that caught my eye. J. Phillip Halstead was the manager of public affairs at Chlorox Co. and was trying to increase the sales of its Kingsford brand of charcoal briquettes. He found that sales would go up 5-15% for each month that had an extra hour of daylight. He said "More light equaled more barbecues and more charcoal briquettes." Halstead now has a consulting business and estimates that the one hour shift is worth about $4 billion in additional sales for outside- based recreation. Another figure: there will be 4 million additional golf games. Cost for this recreation windfall was about $50,000 in lobbying costs. Bob Devine

1 0

Re: Addition to Arthur Olsen/4.3bsd table-driven ctime
by Steve Summit April 6, 1987

April 6, 1987

>> I cannot be sure that my customers will install the necessary >> timezone support files. > Neither can you be sure that they will install /etc/passwd. You don't > handle that, why handle this? /etc/passwd is standard on the systems I'm selling to; /etc/zoneinfo isn't (yet). A customer doesn't have to install /etc/passwd to get my software to run; I know he already has it, or else he's got a broken system, and it's his problem, not mine. >> I insist that both timezone and DST corrections be applied, even in >> the absence of /etc/zoneinfo, which means that ctime must carry >> some DST information along in its data segment, so it can perform >> at least as well as it used to. > This is unclear to me. What I'm worried about here is systems that haven't applied any fixes. I detest "two steps forward, one step back" improvements, so I'm trying to arrange that a ctime that I link into my code behave 100% backwards-compatibly when shipped to a site that depends on using the old ctime. By "backwards-compatibly," I mean that any new ctime, when operating in an environment without /etc/zoneinfo, must generate the same results as (i.e. localtime must be functionally identical to) the "old" versions of ctime. If not, there will be periods of time (such as the three-week period when lazy and/or sensible systems simply set their clock ahead by an hour) during which the new version of ctime will generate a different local time value than the rest of the utilities on the system (date, ls, anything linked with the old ctime) when presented with the same kernel timestamp. >> The next question is, should any DST information hard-compiled >> into ctime be fixed to reflect recent changes? The surprising >> answer is "no." > That means that your worst case is off by an hour. (Ignoring double > DST.) The same as 4.3's. What am I missing? No. It's off by 0 hours, at all times of any past or present year, when shipped to a system that applies no fixes. (Actually, there is a worse worst case, that of the site that applies the fixes in Article 13, to arrive at a temporarily fixed but still non table-driven ctime. I can't arrange for things to work correctly in this case without breaking things in the other two cases, and I consider the other two cases -- the no fix case and the Arthur Olsen case -- more likely.) Actually, no one else here at Tektronix is at all concerned about this issue, and the witching hour has come and gone, so it's probably not worth our thrashing this out. I thought my arguments were fairly convincing, and I tried to sweeten the pot by offering working code, but I admit that these are pretty fine points I'm considering, and since nobody else seems to be interested, I think I'll drop the whole thing and go off and find other damsels to rescue :-). Steve Summit

2 1

Ballot 3 -- struct tm
by seismo!nbires!vianet!devine April 4, 1987

April 4, 1987

On this ballot feel free to mix'n'match your choices. 3. How should the structure tm be defined? a. As it is defined in the SVID with no added members. b. Extend tm structure to contain local timezone offset from UT c. Extend tm structure to contain local seasonal time offset from UT d. Extend tm structure to contain timezone name e. Extend tm structure to contain a pointer to the timezone name f. Drop tm_isdst from the structure. Related questions: 1. If the structure is changed, should it be renamed? 2. What does an invalid structure contain? Can there be invalid struct tm's? 3. If the timezone name is included by a char pointer, how does one make a "permanent" copy of the structure? 4. If the timezone name is included, must there be a standard for timezone names so that a different process can make sense out of a passed structure? 5. How is the structure to be used by the mktime() function.

1 0

ballot 2 - result
by seismo!nbires!vianet!devine April 4, 1987

April 4, 1987

Here are the opinions on how the time_t type should be defined. It may not have been clear what I was getting at with the questions about "how does your favorite machine arch allow for char addressing" or "how do you measure distances". Those questions were meant to show the analogous nature of time measurement to distance and to how one selects a particular point. Time_t has been a single unit measure -- seconds. Compare that with how address for Intel chips are made -- segment and offset. In that scheme, there can be multiple "names" for the same location that can be resolved only be a normalization process. Two of the choices (e, f and maybe b) were also composed of two parts that, while they do extend the range, may have drawbacks based on their form. Distances can be given in a form that has several units (miles, feet, inches). Calculations are easier if there is only one unit; no conversions are needed. Bob Devine ------------------------------------ 2. The type time_t should be defined as: a. a signed long integer whose value is the number of seconds since 1/1/70 0:0:0 UT (the SVID definition) b. an implementation defined type (a long, or struct, or float or ?) c. a signed long integer whose value is the number of seconds since 1/1/70 0:0:0 UT but whose bits may have a special, overloaded meaning d. an unsigned long whose value is the number of seconds since 1/1/70 0:0:0 UT and extends to the year 2100 e. a signed long integer whose value is the number of seconds from a system- or implementation-selected date and time f. a companion value to a date_t where time_t is number of seconds since the start of the day represented in date_t --Bob Devine---------- Choose 'a'. It is too late for a change to happen. Using an "overloaded meaning" time_t will bite those who are not aware of the circumstances where a particular bit pattern is not a simple count-of-seconds. The other choices could be supported with a library that parallels the functions provided by time() and ctime(3) funcs. ---------------------- --Mark Horton--------- I vote for c', namely an unsigned long integer whose value is the number of seconds since 1/1/70 0:0:0 UT but whose bits may have a special, overloaded meaning Namely: all 1's means "error" anything whose 25th through 32nd least significant bits (e.g. the 8 high bits in a 32 bit long) are all 1 is interpreted instead as follows: take the low order 24 bits The time represents 0:0:0 (or any unspecified time) on the date that many days since 0/0/0, as a signed 24 bit integer Alternatively, "error" might be taken as 9 high order 1's, a day 2^23 days BC. ---------------------- --Arthur David Olson-- A. If any other definition is decided on, the type name must be something other than time_t. Any other approach will break existing code. ---------------------- --Tom Hofmann--------- I vote for 'f' -- with 'f' we get more independent and are on the "safe side". ---------------------- --Geoff Kuenning------ For me, (a) is the clear choice. Only (a) and (d) provide effective compatibility for most programs. (c) is just a way to add complexity to a programmer's life without adding real power; everybody will have to deal with the special bits, but the people who actually care about them will not be saved any code over using a more general time type. This is contrary to the "spirit of UNIX". More practically, it is contrary to the principle of simplicity that has made UNIX so wonderful for programmers. (b) and (e) cost too much in portability of existing programs (although (e) is not as bad as first appears, since most time calculations are in effect relative). (f) provides too many ways to represent the same time, which means that many programs would have to have code to normalize time representations to the same date_t before they could manipulate data, again violating the principle of simplicity. It seems to me that there are really two problems here: time stamping and arithmetic on stamps, and general operations on points in time. The existing time_t is adequate for the first. Making it signed doesn't really help with the general problem, but does make it reasonable to represent time differences using a time_t. Of the other options, only (b) and (f) address the general problem, and they do so poorly and at the expense of simplicity and portability. I'd rather either design a really easy-to-use general mechanism, or just punt the problem and say "if you want more, use a private data structure". Note that a truly general solution is pretty difficult, since it is easy to argue for both picosecond resolution and megayear range. Since a year is about 10**7 seconds, this requires a dynamic range of 10**25, or about 2**84. Floating-point is a pretty good answer, though of course it introduces all of the myriad problems of floating arithmetic. > A. Is the range of 1970 +/- 67 years sufficient? Yes and no. One can infer from the lifetimes of OS/8 and IBM's DOS that there will be UNIX machines in operation well past the year 2038. However, it is quite likely that none of the machines will be 32-bitters by then, so the question may become moot. The negative range, of course, is pretty useless for serious date work, but it seems pretty adequate for time differences. However, since there will be files like /bin/true that will still have a 1980's modification date in the 21st century, the negative range must always be able to handle the difference between the current time and the epoch. > B. What is a 'long' for machines with different architectures? K&R guarantee that a long has at least 32 bits. Time_t should not be required to be a C "long" type; it should simply be required to be at least 32 bits. The wide-word types of the future can use their 32-bit shorts if they want, or they can use a 128-bit long to increase accuracy. > C. How is an invalid time represented? Why is it necessary to represent one? If you decide on a representation, then everybody has to check for it. This is one thing with IEEE floating point, where the check can be done in parallel hardware, and quite another with a software type. In any case, what is the meaning of the term "invalid time"? All times are valid; they just might not be accurate. ----------------------

1 0

Re: Berkeley variant of time zone stuff
by seismo!sun!guy April 2, 1987

April 2, 1987

I'm sorry, but I'm not following this whole discussion. It seems to me that S5 has the problem here; Ultimately, it does, but unless and until AT&T fixes the problem there needs to be some way of getting around it. S5 has no way (does it?) to do so. You can set "TZ" to the "proper" value. S5R3.1, and I think some of the earlier versions, at least on the 3Bs, have a file "/etc/TIMEZONE" that can be used to find the "proper" value. > That's why I suggested the "defaultzone" routine - you need some > portable way of setting the TZ environment variable; given existing > systems, removing it isn't a portable way of forcing local wall clock > time. To make this portable, you'll have to alter S5, right? To make it portable to *all* S5 versions distributed by AT&T, you would, but to make it portable to the later ones, you would just have to have "defaultzone" grab the value from TZ. We can't fix every version of S5, but we can fix some of them. Note that "alter(ing) S5" consist only of adding a file "/etc/TIMEZONE" whose contents are something like "TZ=PST5PDT". You don't have to alter any code, you just have to add "/etc/TIMEZONE" and the "defaultzone" routine - or throw in your own version of "defaultzone" and #ifdef it. (Perfect portability can't always be achieved; I'm willing to force people to use #ifdefs on occasion if that makes the code "more portable" in the sense that you have to change less to make it run elsewhere.) The notion here would be to add "defaultzone" to the P1003.1 or X3J11 standard (whichever one discusses the TZ environment variable - not that the October 1 X3J11 draft does NOT discuss TZ, so unless they're going to add it P1003.1 had better think about picking it up). Systems with rational ways of handling TZ can just return a null pointer or the string "localtime"; systems that insist that you set TZ to something parsable can snarf the default value from some file and return that. Also note that this discussion is directed at vendors as well as users; a vendor can always add "/etc/TIMEZONE" and "defaultzone" to their system if they have to.

1 0

Re: Berkeley variant of time zone stuff
by seismo!vianet!devine April 2, 1987

April 2, 1987

I just finished reading Keith Bostic's posted patches for 4.[23] time functions. I disagree with the way that a compiled-in table is still used if the TZ env variable is not defined. Such tables should be extirpated. Note that the new 1987 version of when Daylight Saving Time starts **is not a national law**. Each state can decide to use the first or last Sunday in April to start DST. Each state may decide to even have DST. One lesson the should be learned is that DST rules are extremely changeable. The future holds more possible changes: presidential years may have timezone-dependent DST; Colorado may decide to use year-'round DST (the bill was just introduced last week). Will Berkeley issue a new series of code patches every time a change occurs? Bob Devine

1 0

Re: Berkeley variant of time zone stuff
by seismo!berkeley.edu!bostic%okeeffe April 2, 1987

April 2, 1987

> Point taken; clearly the gettimeofday system call must be retained > (which implies that settimeofday has to hang around too) > to help out old binaries. More importantly, it has to be retained for better than second resolution. > Or "/etc/TIMEZONE". S5R3.1 currently has "init" load up the > environment from what's in "/etc/TIMEZONE". Presumably, you could > have "defaultzone" read the setting of TZ from this... > > or generate a string from the abbreviations and other > information stored in the "/etc/zoneinfo/localtime" file. > > or generate that string. > > But there doesn't seem to be any way to get > unsetenv("TZ") > (the Berkeley posting approach) to give the desired effect of > getting your process--and any children that it later forks > off--running on local wall clock time. If you take that approach > on a System V system, and then fork off an "old" binary, the old > binary will end up using GMT. > I'm sorry, but I'm not following this whole discussion. It seems to me that S5 has the problem here; BSD offers two different ways to guarantee that "localtime" is used, setenv("localtime") and unsetenv("TZ"). S5 has no way (does it?) to do so. Adding another way to BSD won't help the situation. Now, if S5 wanted to add something, I could understand wanting to add it to BSD. > That's why I suggested the "defaultzone" routine - you need some > portable way of setting the TZ environment variable; given existing > systems, removing it isn't a portable way of forcing local wall clock > time. To make this portable, you'll have to alter S5, right? --keith

1 0

Re: Addition to Arthur Olsen/4.3bsd table-driven ctime
by Arthur David Olson April 1, 1987

April 1, 1987

> While working over ctime, I came up with a couple of questions: > > In asctime, shouldn't the year really be printed with %4d > (or maybe %-4d) so that the returned string is guaranteed > to have its advertised 26-character length? (I realize > that the code is lifted directly from the X3J11 draft > standard, and that %d will only get it wrong for dates in > the middle ages that a 32-bit time_t can't begin to reach. > On the other hand, asctime gets handed a broken-down tm > struct, so early years are quite possible.) > > Shouldn't the offtime() routine be declared static? > It's not a publicized interface. > > Steve Summit > stevesu(a)copper.tek.com Even %4d won't guarantee the advertised 26-character length if tm_year is big (or small) enough (for example, 10000); bogus tm_wday and tm_mon values can cause problems as well. You may want to send a note to an X3J11 committee member. offtime was declared static in the mod.sources posting unless STD_INSPIRED was defined. Its eventual fate lies more in the hands of standards committees and other folks wiser than yours truly at this point. --ado

1 0

Re: Berkeley variant of time zone stuff
by Arthur David Olson April 1, 1987

April 1, 1987

First a new question, then stuff inspired by old communicaitons. The new: System V systems run on GMT if there's no TZ environment variable. The new time zone stuff arranges to run on whatever's described in the file "/etc/zoneinfo/localtime" if there's no TZ environment variable. Now you *can* force compatibility either by describing GMT in the file "/etc/zoneinfo/localtime" or by not having the file at all (although this plays hell with the localtime(3) claim that you're getting the "best available approximation to local wall clock time). But would it be a better idea--for the sake of compatibility with System V--for the new time zone stuff to use GMT if there's no TZ environment variable? ---------- ado > > Is there a good reason for keeping the gettimeofday (and ado > > settimeofday) system calls? guy > . . .it has to be provided if binary compatibility with guy > old programs is required; they expect the time zone information to be guy > provided by "gettimeofday". It'd be nice to convert those programs, guy > but this isn't always possible or practical. Point taken; clearly the gettimeofday system call must be retained (which implies that settimeofday has to hang around too) to help out old binaries. A slightly ugly possibility is to conditionalize "/usr/include/sys/time.h": struct timezone { #ifdef KERNEL int tz_minuteswest; int tz_dsttime; #else /* !KERNEL */ int :32; int :32; #endif /* !KERNEL */ }; to preclude use of tz_minuteswest and tz_dsttime when a program is recompiled. This is perhaps more encouragement to convert than is appropriate. :-) One advantage, though, is that the change is invisible to gettimeofday callers who are only interested in getting higher precision time. A find /usr/src -name "*.c" -exec grep -l tz_ {} \; is on my list of things to do. ---------- Guy's reminder about supporting old programs also got me thinking about one of Guy's asides: > On systems where TZ *must* be set for proper operation, you would > have to do put it back into the environment. . .One > possibility here might be to have a function > > char *defaultzone(void); /* X3J11 syntax; no arguments */ > > which returns either a pointer to a string indicating the default > time zone, or a NULL pointer if not setting TZ will cause the system > to use the default time zone. (Admittedly, the latter is a frill; on > systems using Arthur's code, for example, it could just as well > return a pointer to a string containing "localtime".) Setting TZ to "localtime" would work fine on a BSD system--"new" programs would be using the new time zone stuff and would honor it; "old" programs would be calling gettimeofday. But if it's a System V system with "old" binaries, "localtime" probably isn't what you want to put in the environment, since doing that would convince such child processes that you wanted to run on GMT with the time zone abbreviation "loc". There are a couple of ways to get around this--set up a "/etc/zoneinfo/defaultzone" file that contains the value to return, or generate a string from the abbreviations and other information stored in the "/etc/zoneinfo/localtime" file. But there doesn't seem to be any way to get unsetenv("TZ") (the Berkeley posting approach) to give the desired effect of getting your process--and any children that it later forks off--running on local wall clock time. If you take that approach on a System V system, and then fork off an "old" binary, the old binary will end up using GMT. I think the simple way out here just to avoid promising a way of getting your process and its unborn children running on local time. I still *do* want to provide a way to get your process--though not necessarily its unborn children-- running on local time; either unsetenv("TZ") or tzsetwall() does this job. The wise words from California are that unsetenv("TZ") is the way to go; are there any other words? --ado

1 0

Re: AT&T clock (synchronization)
by seismo!nbires!vianet!devine April 1, 1987

April 1, 1987

Mark writes: > I am unaware of any master clock in AT&T used for sync. I do know > that it's quite common for the clock in each central office to run > at a significantly different rate. I just got a reply back from a friend who works for AT&T in Denver. He says: > I'm not too sure about how central offices are set up for clock timing. > My past work in AT&T was with the long-distance calling switches (toll > offices). Back when AT&T was a monopoly, all the toll switching centers > kept their internal clocks in sync via a high-precision clock located > somewhere in Missouri. Presumably (but I'm not sure), the toll centers > passed along clock sync information to any connected tandem or local > central offices. With the breakup, all of this stuff must have been changed > dramatically. Bob Devine

1 0

Re: Addition to Arthur Olsen/4.3bsd table-driven ctime
by seismo!berkeley.edu!bostic%okeeffe March 31, 1987

March 31, 1987

> I cannot be sure that my customers will install the necessary > timezone support files. Therefore, any copy of ctime linked into > my programs must work "correctly" when transported to a machine > without /etc/zoneinfo in place. Neither can you be sure that they will install /etc/passwd. You don't handle that, why handle this? Not that I think that defaulting to GMT is correct, I don't. However, I can trivially fix it so that worst case is off by an hour. Which seems sufficient. > I insist that both timezone and DST corrections be applied, even in > the absence of /etc/zoneinfo, which means that ctime must carry > some DST information along in its data segment, so it can perform > at least as well as it used to. This is unclear to me. > The next question is, should any DST information hard-compiled > into ctime be fixed to reflect recent changes? The surprising > answer is "no." That means that your worst case is off by an hour. (Ignoring double DST.) The same as 4.3's. What am I missing? --keith > Steve Summit > stevesu(a)copper.tek.com

1 0

Addition to Arthur Olsen/4.3bsd table-driven ctime
by seismo!rutgers!lll-lcc!cae780!tektronix.TEK.COM!copper.TEK.COM!stevesu March 30, 1987

March 30, 1987

(This is essentially the article I just posted to comp.unix.wizards and comp.bugs.4bsd). First, let me thank you guys for the work that has gone into this new ctime. A table-driven approach is clearly the only way to go, and this one works admirably well. (I can't believe how fast it is, and how small both ctime.o and the zoneinfo files are.) I foresee one problem with its use, however, which I'll describe, along with a proposed solution. Suppose I'm a software vendor (which I am, or at least I work for one), and I ship binary executables to my customers (which I do), executables which reference ctime and friends (which they do). What, if anything, should I do to ctime on my development system? I cannot be sure that my customers will install the necessary timezone support files. Therefore, any copy of ctime linked into my programs must work "correctly" when transported to a machine without /etc/zoneinfo in place. The version posted to net.sources defaulted to GMT in the absence of /etc/zoneinfo. The "Official 4.3BSD" version posted last week arranges that local timezone correction be applied in this situation, based on the kernel's notion of the timezone. I insist that both timezone _a_n_d DST corrections be applied, even in the absence of /etc/zoneinfo, which means that ctime must carry some DST information along in its data segment, so it can perform at least as well as it used to. The next question is, should any DST information hard-compiled into ctime be fixed to reflect recent changes? The surprising answer is "no." For sites which have installed /etc/zoneinfo, the up-to-date tables found there will take precedence. At sites without /etc/zoneinfo, the safest assumption is that they have not really dealt with the ctime problem at all, but are tweaking the system clock (in the case of the upcoming change in the US, setting the clock ahead one hour on April 5, and setting it back an hour on April 26, when the old ctime thinks DST kicks in). Such a strategy is reasonable, and works fine as long as the DST correction applied by date(1) when the internal GMT is set matches the correction applied by each and every program when GMT is converted back to local time. An executable with a "fixed" version of ctime would in fact behave incorrectly at such a site. Therefore, the DST information hard-coded into any improved version of ctime must be exactly as broken as the old, "standard" one. In that way, it will work equally well on systems that have done no more to deal with the DST change than changing their clocks for three weeks, and on systems that have adopted the proposed fix. (The only flaw in this theory is the possibility that people on some systems have prolonged their agony by going to the trouble of relinking everything, but with a "fixed" ctime that still relies only on compiled-in tables. This approach is in fact the one suggested by Keith Bostic's "ARTICLE 13." If anybody is considering this, take my advice and don't. If you're in a position to relink at all, it's really no more trouble to use the table-driven ctime, and that way you won't have to worry the next time the DST rules change.) Herewith are context diffs, against the 4.3 version posted by Keith Bostic last week, of a version of the Arthur Olsen ctime that works in a backwards-compatible way in the absence of /etc/zoneinfo. (I am also posting the complete, modified version to net.sources.) The code actually uses the same DST tables as the old 4.1/4.2 ctime, to guarantee compatibility. The old-style tables are automatically converted into the internal state lists needed by the new ctime's algorithm. (These diffs still reflect some debugging code I added, to verify that my new code was building correct internal data structures. I did regression tests against real state lists created by zic from a kludged-up description file reflecting the old transition dates.) I should point out that I have not tested the new code in the southern hemisphere case, and I suspect that it will get things wrong there for the first four months of 1970. (This code only attempts to perform DST correction after 1970, anyway. In that respect, it may be incompatible with the old ctime, which applied DST in years prior to 1970 if you passed it a negative time. The type of the internal variables has been bouncing back and forth between `long' and `unsigned long' as people try to decide how it should work.) While working over ctime, I came up with a couple of questions: In asctime, shouldn't the year really be printed with %4d (or maybe %-4d) so that the returned string is guaranteed to have its advertised 26-character length? (I realize that the code is lifted directly from the X3J11 draft standard, and that %d will only get it wrong for dates in the middle ages that a 32-bit time_t can't begin to reach. On the other hand, asctime gets handed a broken-down tm struct, so early years are quite possible.) Shouldn't the offtime() routine be declared static? It's not a publicized interface. Steve Summit stevesu(a)copper.tek.com *** ctime.orig.c Sun Mar 29 16:11:46 1987 --- ctime.c Mon Mar 30 11:27:22 1987 *************** *** 215,220 #endif /* USG_COMPAT */ } } return 0; } --- 215,223 ----- #endif /* USG_COMPAT */ } } + #ifdef DEBUG + printstate(); + #endif return 0; } *************** *** 218,223 return 0; } static tzsetkernel() { --- 221,244 ----- return 0; } + #ifdef DEBUG + + printstate() + { + int i; + + printf("TS/DST info state:\n"); + for(i = 0; i < s.timecnt; i++) + printf("time %d: %ld %d\n", i, s.ats[i], s.types[i]); + for(i = 0; i < s.typecnt; i++) + printf("type %d: %ld %d %d (%s)\n", i, + s.ttis[i].tt_gmtoff, s.ttis[i].tt_isdst, + s.ttis[i].tt_abbrind, + s.chars + s.ttis[i].tt_abbrind); + } + + #endif + static tzsetkernel() { *************** *** 224,229 struct timeval tv; struct timezone tz; char *tztab(); if (gettimeofday(&tv, &tz)) return -1; --- 245,251 ----- struct timeval tv; struct timezone tz; char *tztab(); + static dstsetkernel(); if (gettimeofday(&tv, &tz)) return -1; *************** *** 227,233 if (gettimeofday(&tv, &tz)) return -1; ! s.timecnt = 0; /* UNIX counts *west* of Greenwich */ s.ttis[0].tt_gmtoff = tz.tz_minuteswest * -SECS_PER_MIN; s.ttis[0].tt_abbrind = 0; (void)strcpy(s.chars, tztab(tz.tz_minuteswest, 0)); --- 249,257 ----- if (gettimeofday(&tv, &tz)) return -1; ! s.timecnt = 0; ! s.typecnt = 1; ! /* UNIX counts *west* of Greenwich */ s.ttis[0].tt_gmtoff = tz.tz_minuteswest * -SECS_PER_MIN; s.ttis[0].tt_isdst = 0; s.ttis[0].tt_abbrind = 0; *************** *** 229,234 return -1; s.timecnt = 0; /* UNIX counts *west* of Greenwich */ s.ttis[0].tt_gmtoff = tz.tz_minuteswest * -SECS_PER_MIN; s.ttis[0].tt_abbrind = 0; (void)strcpy(s.chars, tztab(tz.tz_minuteswest, 0)); tzname[0] = tzname[1] = s.chars; --- 253,259 ----- s.typecnt = 1; /* UNIX counts *west* of Greenwich */ s.ttis[0].tt_gmtoff = tz.tz_minuteswest * -SECS_PER_MIN; + s.ttis[0].tt_isdst = 0; s.ttis[0].tt_abbrind = 0; (void)strcpy(s.chars, tztab(tz.tz_minuteswest, 0)); tzname[0] = tzname[1] = s.chars; *************** *** 236,241 timezone = tz.tz_minuteswest * 60; daylight = tz.tz_dsttime; #endif /* USG_COMPAT */ return 0; } --- 261,274 ----- timezone = tz.tz_minuteswest * 60; daylight = tz.tz_dsttime; #endif /* USG_COMPAT */ + + if(tz.tz_dsttime) + dstsetkernel(&tz); + + #ifdef DEBUG + printstate(); + #endif + return 0; } *************** *** 386,389 tmp->tm_zone = ""; tmp->tm_gmtoff = offset; return tmp; } --- 419,615 ----- tmp->tm_zone = ""; tmp->tm_gmtoff = offset; return tmp; + } + + /* + * Backwards-compatible DST information tables. + * + * The tables give the day number of the first day after the + * Sunday of the change. + * + * DO NOT FIX THESE TABLES. + * Yes, they're wrong in several ways, including 1987 and beyond + * in the United States, but they happen to match the old ctime.c + * that is compiled into virtually all programs under 4.2bsd- + * derived systems. This is important if programs compiled with + * this version of ctime are to work correctly when shipped (in + * binary form) to systems which have not upgraded to the + * /etc/zoneinfo scheme. + * + * These hardwired tables are only used when /etc/zoneinfo cannot + * be accessed. A system which does not have /etc/zoneinfo is + * probably handling DST fluctuations by changing the system clock. + * Therefore, all programs on such a system (whether linked with + * old or new versions of ctime) must use the same DST rules. + * On a system with old-fashioned versions of ctime, handling + * DST fluctuations by changing the system clock, a "correct" + * version of ctime would in fact display incorrect results. + */ + + struct dstab { + int dayyr; + int daylb; + int dayle; + }; + + static struct dstab usdaytab[] = { + 1974, 5, 333, /* 1974: Jan 6 - last Sun. in Nov */ + 1975, 58, 303, /* 1975: Last Sun. in Feb - last Sun in Oct */ + 0, 119, 303, /* all other years: end Apr - end Oct */ + }; + + static struct dstab ausdaytab[] = { + 1970, 400, 0, /* 1970: no daylight saving at all */ + 1971, 303, 0, /* 1971: daylight saving from Oct 31 */ + 1972, 303, 58, /* 1972: Jan 1 -> Feb 27 & Oct 31 -> dec 31 */ + 0, 303, 65, /* others: -> Mar 7, Oct 31 -> */ + }; + + /* + * The European tables ... based on hearsay + * Believed correct for: + * WE: Great Britain, Ireland, Portugal + * ME: Belgium, Luxembourg, Netherlands, Denmark, Norway, + * Austria, Poland, Czechoslovakia, Sweden, Switzerland, + * DDR, DBR, France, Spain, Hungary, Italy, Jugoslavia + * Eastern European dst is unknown, we'll make it ME until someone speaks up. + * EE: Bulgaria, Finland, Greece, Rumania, Turkey, Western Russia + */ + + static struct dstab wedaytab[] = { + 1983, 86, 303, /* 1983: end March - end Oct */ + 1984, 86, 303, /* 1984: end March - end Oct */ + 1985, 86, 303, /* 1985: end March - end Oct */ + 0, 400, 0, /* others: no daylight saving at all ??? */ + }; + + static struct dstab medaytab[] = { + 1983, 86, 272, /* 1983: end March - end Sep */ + 1984, 86, 272, /* 1984: end March - end Sep */ + 1985, 86, 272, /* 1985: end March - end Sep */ + 0, 400, 0, /* others: no daylight saving at all ??? */ + }; + + static struct dayrules { + int dst_type; /* number obtained from system */ + int dst_hrs; /* hours to add when dst on */ + struct dstab * dst_rules; /* one of the above */ + enum {STH,NTH} dst_hemi; /* southern, northern hemisphere */ + } dayrules [] = { + DST_USA, 1, usdaytab, NTH, + DST_AUST, 1, ausdaytab, STH, + DST_WET, 1, wedaytab, NTH, + DST_MET, 1, medaytab, NTH, + DST_EET, 1, medaytab, NTH, /* XXX */ + -1, + }; + + static + dstsetkernel(tzp) + struct timezone *tzp; + { + struct dayrules *drp; + int tabsize; + int timei; + int y; + int yleap; + int i; + int d, di; + time_t t; + int daylb, dayle; + char *p; + + for(drp = dayrules; drp->dst_type >= 0; drp++) + if(drp->dst_type == tzp->tz_dsttime) + break; + + if(drp->dst_type < 0) + return; + + /* this ends up computing tabsize - 1, but that's what we want */ + + for(tabsize = 0; drp->dst_rules[tabsize].dayyr > 0; tabsize++) + ; + + /* 2038 is the year that signed 32 bit time_t's give out */ + + for(y = 1970, d = 0, t = 0, timei = 0; y < 2038; y++) { + daylb = drp->dst_rules[tabsize].daylb; + dayle = drp->dst_rules[tabsize].dayle; + + for(i = 0; i < tabsize; i++) + if(y == drp->dst_rules[i].dayyr) { + daylb = drp->dst_rules[i].daylb; + dayle = drp->dst_rules[i].dayle; + break; + } + + yleap = isleap(y); + + if(yleap) { + if(daylb >= 58) + daylb++; + + if(dayle >= 58) + dayle++; + } + + /* + * January 1, 1970 was a Wednesday. + * d is the difference between January 1 of the loop + * year (y) and January 1, 1970, in days. + * daylb and dayle are (0-origin) day offsets with + * respect to January 1. + * So (d + dayl[be] - 3) % 7 is the day (0 == Sunday) + * of daylb or dayle. + * That's also the number to subtract from daylb or + * dayle to get the day number (since January 1 of + * the loop year) of the preceding Sunday. + */ + + daylb -= (d + daylb - 3) % 7; + dayle -= (d + dayle - 3) % 7; + + s.ats[timei] = t + SECS_PER_DAY * daylb + + tzp->tz_minuteswest * SECS_PER_MIN + + 2 * SECS_PER_HOUR; + + s.ats[timei + 1] = t + SECS_PER_DAY * dayle + + tzp->tz_minuteswest * SECS_PER_MIN + + (drp->dst_hemi == NTH ? 1 : 2) + * SECS_PER_HOUR; + + if(drp->dst_hemi == NTH) { + s.types[timei] = tzp->tz_dsttime; + s.types[timei + 1] = 0; + } else { + s.types[timei] = 0; + s.types[timei + 1] = tzp->tz_dsttime; + } + + timei += 2; + + di = year_lengths[yleap]; + + d += di; + t += di * SECS_PER_DAY; + } + + s.timecnt = timei; + + s.ttis[1].tt_gmtoff = tzp->tz_minuteswest * -SECS_PER_MIN + + drp->dst_hrs * SECS_PER_HOUR; + + s.ttis[1].tt_isdst = tzp->tz_dsttime; + + for(p = s.chars; *p != '\0'; p++) + ; + + (void)strcpy(++p, tztab(tzp->tz_minuteswest, tzp->tz_dsttime)); + + s.ttis[1].tt_abbrind = p - s.chars; + + tzname[1] = p; + + s.typecnt = 2; }

1 0

Re: Berkeley variant of time zone stuff
by seismo!sun!guy March 30, 1987

March 30, 1987

The reason I put that code in was because I actually had the code running on a machine that I couldn't put the /etc/zoneinfo directory on. And, for a couple of days, I got a first hand look at what happens when things are 8 hours off. With the current code, it would require a major kernel problem to be more than an hour off. Isn't that worth having? Well, I don't know that it's that much better to be one hour off than 8 hours off. Also, there are plenty of files that, if missing or inaccessible, will cause UNIX some amount of distress; I'm not sure the time zone files are worth singling out. (E.g., why not put code into "init" so that the system will work even if "getty" is missing or won't work? Why not put code into the kernel to try opening "/dev/console" and running "/bin/sh" if "/etc/init" can't be found?) In Olson's scheme, if the time zone files are inaccessible, it will be pretty obvious and the administrator will find those files, by hook or by crook. I don't consider it that likely that they'd be missing or inaccessible, either.

1 0

Re: Berkeley variant of time zone stuff
by seismo!berkeley.edu!bostic%okeeffe March 29, 1987

March 29, 1987

> It may be, however, that the best way to ream out the environment is > just to do > > extern char **environ; > static char *nullenv = NULL; > > ... > > environ = &nullenv; > > and be done with it. The Berkeley man page for getenv has the comment: Unsetenv removes all occurrences of the string name from the environment. There is no library provision for completely removing the current environment. It is suggested that the following code be used to do so. static char *envinit[1]; extern char **environ; environ = envinit; >> Second, what about the notion of trying for localtime >> (before defaulting to GMT) if the TZ environment variable >> contains something nonsensical? I eventually decided >> against trying for local time; it makes for (very >> marginally) simpler code, and I thought that (for US >> users at least) getting dates reported in GMT would be >> likelier to serve notice that something was wrong with >> the TZ variable. > I agree 100%. The reason I put that code in was because I actually had the code running on a machine that I couldn't put the /etc/zoneinfo directory on. And, for a couple of days, I got a first hand look at what happens when things are 8 hours off. With the current code, it would require a major kernel problem to be more than an hour off. Isn't that worth having? --keith

1 0

Re: Berkeley variant of time zone stuff
by seismo!sun!guy March 28, 1987

March 28, 1987

Is Berkeley's "unsetenv" approach the right one to take to give processes a way of guaranteeing that they run on local wall clock time? Is "tzsetwall" the way to go? Is there some other, better approach? "unsetenv" is the right approach to take to give processes a way of guaranteeing that neither they nor any child processes they spawn will have their behavior affected by the values of environment variables at the time they were run. TZ is one such environment variable, but LOGNAME, USER, and PATH are others. This behavior is necessary for daemon processes that are started as part of a user's session rather than as part of the booting process; e.g., "uucico". It may be, however, that the best way to ream out the environment is just to do extern char **environ; static char *nullenv = NULL; ... environ = &nullenv; and be done with it. On systems where TZ *must* be set for proper operation, you would have to do put it back into the environment after doing this. One possibility here might be to have a function char *defaultzone(void); /* X3J11 syntax; no arguments */ which returns either a pointer to a string indicating the default time zone, or a NULL pointer if not setting TZ will cause the system to use the default time zone. (Admittedly, the latter is a frill; on systems using Arthur's code, for example, it could just as well return a pointer to a string containing "localtime".) A routine would be needed that took a TZ string and used that string to set up the time zone tables. This routine could either be exported (my preference) or kept static. "tzset" would pass the value of the environment variable TZ to this routine; "tzsetwall" would pass the value returned by "defaultzone". A program that wanted to ensure that any children it spawned also used the default time zone would remove TZ from the environment and then call "defaultzone". If the result were non-NULL, it would put that result into the environment as the value of TZ; otherwise, it would just leave TZ out of the environment. First, it would seem to me that having two ways of specifying what local time should be--the /etc/zoneinfo/localtime file, and the results of a gettimeofday system call--is a bad idea. Is there a good reason for keeping the gettimeofday (and settimeofday) system calls? Yes. For one thing, in addition to providing the time zone information, they also provide a higher-resolution system clock. This is useful for determining intervals of real time to higher resolution than one second and, if your machine has a clock that keeps correct time to that resolution, is useful for putting higher-resolution time stamps on events. For another thing, it has to be provided if binary compatibility with old programs is required; they expect the time zone information to be provided by "gettimeofday". It'd be nice to convert those programs, but this isn't always possible or practical. It's unfortunate that this provides another way to get at the time zone information, but that can't really be helped. Note that the "time zone type" part of this information is difficult to use; you'd need to get at the information that currently only appears as hard-coded tables inside "ctime.c", and that doesn't even appear there if you replace the old version of "localtime" with the new stuff. Should the time zone stuff include a replacements for gettimeofday? For settimeofday? No. The time zone stuff does provide a replacement for the time zone part of "{get,set}timeofday". A replacement for the current-time-to-higher-resolution part falls outside of the purview of the time zone stuff; it would be nice if P1003 provided something like this - maybe by providing 4BSD-style "struct timeval"s, or some other high-precision time value, and providing a "getclock" routine that gets that without getting the timezone information ("stime" isn't in P1003, so neither should "setclock"). Should gettimeofday and settimeofday be unceremoniously dropped? They're not in P1003 or the time zone stuff, so there's nothing to drop there. They can't be dropped from systems that provide them, because that would break too many existing programs. Second, what about the notion of trying for localtime (before defaulting to GMT) if the TZ environment variable contains something nonsensical? I eventually decided against trying for local time; it makes for (very marginally) simpler code, and I thought that (for US users at least) getting dates reported in GMT would be likelier to serve notice that something was wrong with the TZ variable. I agree 100%. 3. Berkeley forged ahead and added the "tm_gmtoff" and "tm_zone" elements to the tm structure. 4. Berkeley retained the "solar87" file but in their default distribution it doesn't get compiled (and defines used in localtime and friends are not set up to allow its use); the mod.sources posting does compile the solar87 file (and defines things so that it can be used) unless you take steps otherwise. Is the Berkeley approach best here? Note that the mod.sources posting provides something that you can drop directly into your system if you want, but that you may very well want to modify. As such, I think the mod.sources postings should continue to be set up the way they are; resuppliers of that code (Berkeley, CMU, Sun and other vendors) can set the configuration parameters the way they want. If we end up proposing "tm_gmtoff" and "tm_zone" to P1003 or X3J11, we may want to arrange that they're in by default and that you'd have to take special action to remove them, just to encourage people to provide them.

1 0

Berkeley variant of time zone stuff
by Arthur David Olson March 28, 1987

March 28, 1987

The folks at Berkeley have posted a slight variant of the recent mod.sources time zone posting to comp.bugs.4bsd.ucb-fixes. I'd like to note some of the differences, comment on the differences, and ask for opinions on what to do with Berkeley's changes. 1. Berkeley has dropped the "tzsetwall" function. You call tzsetwall to arrange for "localtime" to deliver the best available approximation to local wall clock time. Berkeley's approach is to provide an "unsetenv" function so that folks can do an unsetenv("TZ") call before calling localtime; since the mod.sources version of the time zone stuff uses local wall clock time if TZ is absent from the environment, this has the desired effect. As Keith Bestic (:-)) notes, this also has the advantage of arranging for forked-off processes to run on local wall clock time. The disadvantage I see here is in porting code to old systems. Take, for example, "sysdate.c", which is designed to print out the system's idea of wall clock time regardless of what the user has set TZ to (potentially useful when calling a system in Paris from Podunk): #include "stdio.h" #include "sys/types.h" extern char * ctime(); main(argc, argv) int argc; char * argv[]; { time_t now; unsetenv("TZ"); tzset(); (void) time(&now); (void) printf("%s", ctime(&now)); return 0; } Now suppose this code lands on a System V Release 2 machine. Our hypothetical code porter tries to compile it and gets an Undefined: _unsetenv diagnostic. The porter then goes ahead and implements unsetenv, and things compile just fine--but when "sysdate" is run, it spits out GMT, which is what System V Release 2 does when TZ is absent from the environment. Is Berkeley's "unsetenv" approach the right one to take to give processes a way of guaranteeing that they run on local wall clock time? Is "tzsetwall" the way to go? Is there some other, better approach? 2. The mod.sources version of "tzset" tries to load up the time zone information specified in the TZ environment variable; if this fails, it sets things up so that GMT is used. The comp.bugs.4bsd.ucb-fixes version: tries to load up the time zone information specified by TZ; if that fails, tries to load up "localtime"; if *that* fails, tries to load up information based on what a "gettimeofday" system call returns; and if *that* fails, loads up GMT. First, it would seem to me that having two ways of specifying what local time should be--the /etc/zoneinfo/localtime file, and the results of a gettimeofday system call--is a bad idea. Is there a good reason for keeping the gettimeofday (and settimeofday) system calls? Should the time zone stuff include a replacements for gettimeofday? For settimeofday? Should gettimeofday and settimeofday be unceremoniously dropped? Second, what about the notion of trying for localtime (before defaulting to GMT) if the TZ environment variable contains something nonsensical? I eventually decided against trying for local time; it makes for (very marginally) simpler code, and I thought that (for US users at least) getting dates reported in GMT would be likelier to serve notice that something was wrong with the TZ variable. 3. Berkeley forged ahead and added the "tm_gmtoff" and "tm_zone" elements to the tm structure. 4. Berkeley retained the "solar87" file but in their default distribution it doesn't get compiled (and defines used in localtime and friends are not set up to allow its use); the mod.sources posting does compile the solar87 file (and defines things so that it can be used) unless you take steps otherwise. Is the Berkeley approach best here? --ado

1 0

Ballot #1 -- results
by seismo!nbires!vianet!devine March 26, 1987

March 26, 1987

Ballot # 1 -- Results # votes ------- 1. Fate of external variables "daylight", "timezone", and "tzname[]" 4 | a. Don't put in standard and discourage use. 2 | b. Don't put in standard and allow implementation-optional use. 2 | c. Place in standard as currently defined in SVID. 2 | d. Place in standard but with different or expanded definitions. OVERALL: Replies for the first round of issues took longer than I anticipated. Also, I am breaking one of my rules: the results will not be piggybacked on a following ballot. I would guess that everyone was looking at the larger picture than just this issue, that is, this issue will fall out of the complete design. The actual count depends on how I read the emphasis of the explanatory text. This ballot might be reissued later when other agreements have been reached. Ballot 2 will be sent out tomorrow night (gotta go home now!) Bob Devine ============================= VOTES ======================================== Bob Devine--------------- Choose 'a'. But I am anticipating how I will vote on "struct tm". The future of the two are intertwined. If can't modify tm, change to d. ------------------------- Arthur Olson------------- Any of the above outcomes are acceptable to me. My favorite with regard to daylight and timezone: a My favorite with regard to tzname: d ------------------------- Chris Torek-------------- b. it should be noted that 4.3BSD does not match SysV, so mandating SVID breaks existing code, and is insufficent ------------------------- dreamit!jjw-------------- My vote > d. Place in standard but with different or expanded definitions. I would like to see a minor extension of the SVID: Make "daylight" an index into "tzname" and allow tzname to be more than 2 elements long. This would allow an easy pickup of the appropriate name and would also allow for those few cases where there are more than one type of daylight savings, e.g "double daylight time". ------------------------- Dennis Mumaugh----------- Vote: d Current definition in SVID is chauvinistic and USA oriented. It assumes that DST is always one hour offset from standard time and that it is advanced. Also one alternate time zone name and one alternate time zone offset. Daylight needs to be changed in meaning, timezone needs to be long timezone[MAXTZ]; offset is derived by timezone[daylight]; and tzname needs to be char *tzname[MAXTZ]; Thus header is #define MAXTZ 10 /* maximum possible changes in Time Rules per year */ time_t timezone[MAXTZ] /* offset from GMT for each Time Rule */ char *tzname[MAXTZ]; /* name of each Rule */ long daylight; /* 0 <= daylight < MAXTZ */ ------------------------- Guy Harris--------------- I vote for a. - Don't put in standard and discourage use. Implementations can provide them if they want, so a. doesn't disallow implementation-optional use. I prefer a. to b. and c. because, as they stand, they may not be able to describe all the wrinkles people can add to their DST rules, and so I'd prefer to discourage them. I prefer a. to d. because 1) I prefer not to use global variables if at all possible and 2) with something like "timelocal" or "mktime", and the Elz-style fields added to "struct tm", it should not be necessary for anybody to need direct access to things like "daylight", "timezone", etc., and the internal data structures used by those routines should be hidden. ------------------------- Mark Horton-------------- Either c or d is OK with me; first choice I guess is c unless a better idea appears. I think it's important to have the conventions for finding out the time zone as part of the standard - I have lots of unportable code because it isn't. ------------------------- Geoff Kuenning----------- I vote (c). If they aren't in the standard, it will break a lot of existing code when manufacturers drop them. I don't like it, but we shouldn't break existing code just because it's ugly. ------------------------- Ron Tolley--------------- I find it difficult to vote on this issue before some other issues have been resolved. Therefore, I will vote conditionally: If the tm structure is changed to provide 1) the difference from GMT in seconds and 2) pointer to a string which contains the time zone name, then vote (a), otherwise vote (c). In either case daylight should not be included in the standard. ------------------------- Shane P. McCarron-------- My response to this question would be b. We have done this with a number of other issues - where the wishes of the committee conflict with reality. I think that this is something that is so in place that we cannot simply write it off. It is interesting to note that the only place I find a reference to timezone in the X3 document is in section 4.12, where it says "The local time zone and Daylight Savings Time are implementation-defined." POSIX has stated (at the December meeting) that we will bow to X3 and X/OPEN for specifics about the timezone stuff. This looks like the answer right here. -------------------------

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!hplabs!felix!peregrine.peregrine.com!mike March 26, 1987

March 26, 1987

How about having an epoch_t date type which is the number of epochs since a "super-epoch" the advantage of this is that there would be on unique encoding for each date/time. This would aid in both comparison and conversion of times. Any comments?

1 0