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