April 1987 - tz - lists.iana.org

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