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