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.