These time and date functions are much like the System V Release 2.0 (SVR2)
time and date functions; there are a few additions and changes to extend
the usefulness of the SVR2 functions:

*	In SVR2, time display in a process is controlled by the environment
	variable TZ, which "must be a three-letter time zone name, followed
	by a munber representing the difference between local time and
	Greenwich Mean Time in hours, followed by an optional three-letter
	name for a daylight time zone;" when the optional daylight time zone is
	present, "standard U.S.A. Daylight Savings Time conversion is applied."
	This means that SVR2 can't deal with other (for example, Australian) 
	daylight savings time rules, or situations where more than two
	time zone abbreviations are used in an area.

*	In SVR2, time conversion information is compiled into each program
	that does time conversion.  This means that when time conversion
	rules change (as in the United States in 1987), all programs that
	do time conversion must be recompiled to ensure proper results.

*	In SVR2, time conversion fails for near-minimum or near-maximum
	time_t values when doing conversions for places that don't use GMT.

*	In SVR2, there's no tamper-proof way for a process to learn the
	system's best idea of local wall clock.  (This is important for 
	applications that an administrator wants used only at certain times--
	without regard to whether the user has fiddled the "TZ" environment
	variable.

These are the changes that have been made to the SVR2 functions:

*	The "TZ" environment variable is used in generating the name of a file
	from which time zone information is read; "TZ" is no longer constrained
	to be a three-letter time zone name followed by a number of hours and
	an optional three-letter daylight time zone name.  The daylight saving
	time rules to be used for a particular time zone are encoded in the
	time zone file; the format of the file allows U.S., Australian, and
	other rules to be encoded, and allows for situations where more than
	two time zone abbreviations are used.

	It was recognized that allowing the "TZ" envirnoment variable to
	take on values such as "US/Eastern" might cause "old" programs
	(that expect "TZ" to have a certain form) to operate incorrectly;
	consideration was given to using some other environment variable
	(for example, "TIMEZONE") to hold the string used to generate the
	time zone information file name.  In the end, however, it was decided
	to continue using "TZ":  it is widely used for time zone purposes;
	separately maintaining both "TZ" and "TIMEZONE" seemed a nuisance;
	and systems where "new" forms of "TZ" might cause problems can simply
	give time zone files names such as "EST5EDT" which can be used both by
	"new" programs (as file names) and "old" programs (as zone names and
	offsets).

*	To handle places where more than two time zone abbreviations are used,
	the functions "localtime" and "gmtime" set tzname[tmp->tm_isdst]
	(where "tmp" is the value the function returns) to the time zone
	abbreviation to be used.  This differs from SVR2, where the elements
	of tzname are only changed as a result of calls to tzset.

*	Since the "TZ" environment variable can now be used to control time
	conversion, the "daylight" and "timezone" variables are no longer
	needed or supported.  (You can use a compile-time option to cause
	these variables to be defined and to be set by "tzset"; however, their
	values will not be used by "localtime.")

*	The "localtime" function has been set up to deliver correct results
	for near-minimum or near-maximum time_t values.  (You can use a
	compile-time option to make localtime behave--incorrectly--in the
	same way SVR2's localtime does.)

*	A function "tzsetwall" has been added to arrange for the system's
	best approximation to local wall clock time to be delivered by
	subsequent calls to "localtime."  Source code for portable
	applications that "must" run on local wall clock time should call
	"tzsetwall;" if such code is moved to "old" systems that don't provide
	tzsetwall, you won't be able to generate an executable program.
	(These time zone functions also arrange for local wall clock time to be
	used if tzset is called--directly or indirectly--and there's no "TZ"
	environment variable; portable applications should not, however, rely
	on this behavior since it's not the way SVR2 systems behave.)
