Berkeley variant of time zone stuff

[Guy Harris]

	     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.