Berkeley variant of time zone stuff

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