Berkeley variant of time zone stuff

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