Conversation with Ron Tolley

Guy Harris seismo!sun!guy
Mon Dec 8 20:51:55 UTC 1986

		...instead use some new environment variable--for example
		With this approach, old executables don't get confused by zone
		information that's in a new format since the new-format
		information is put in a place that the old executables don't
		look.  The disadvantage of this approach is that old
		executables don't get *any* information about what the user

Old executables can't necessarily give the user what they want anyway; for
example, they won't give people in South Australia what they presumably want.

		(Implementation point:  new software would presumably first
		look for "ZONE" in the environment and then fall back on "TZ"
		if "ZONE" was absent from the environment.)

If "TZ" is to be parsed, rather than used as a file name, you'd have to
indicate which rules are used; presumably, you can use the US rules (i.e.,
hardcode the current rules, or the current rules as modified for the 1987
change), since that leaves people no worse off than they are now.

Also, I'd vote to change "ZONE" to "TIMEZONE"; environment variables don't
need to have short names, and you might as well give them a name that more
precisely explains what they do.

One minor nuisance with this is that a program would have to smash both
"ZONE" and "TZ" in order to guarantee that they'll get the CPU's local time
(we ignore the possibility of the CPU being in one time zone and the modems,
or the bulk of the terminals, being in another :-)).

	    If, on the other hand, I write code that calls
	    the code won't compile at all on existing System V systems.

Did they really mean programs call "gettimeofday" directly?  All
"gettimeofday" returns is the current UNIX clock time (which is in GMT/UTC)
and, optionally, a structure indicating the current offset from GMT and rule
set to be used to handle DST.  As such, you'd have to duplicate much of
"localtime" to use this data, which seems excessive, and it would still
suffer from the disadvantages of the 4BSD scheme.

	    One possibility I'd see:  drop the demand that local wall clock
	    time be used if TZ is absent from the environment,

No!  It is difficult, if not impossible, to guarantee that TZ will be
properly set in the environment.  Forcing every use to stick something in
their ".profile" or ".login" is gross, and also doesn't work if your login
shell is neither "/bin/sh" nor "/bin/csh".  This would screw not only login
"shells" like "/usr/lib/uucp/uucico" (although it doesn't *want* TZ to be
set, it always wants the machine's local time) but also things like office
automation systems and other applications that put you into a special
environment when you log in.  Those applications don't necessarily know
anything about shell scripts, so they can't just scan ".profile" or
"/etc/profile" or whatever.

	    and add a function such as
	    that returns "the best available approximation of local wall
	    clock time regardless of the setting of the TZ environment
	    variable."  It would be a close analog of "gmtime".

This is a bit complicated; I'd prefer something like


which acts like "tzset()" except that it looks neither at "TZ" nor at
"TIMEZONE" but forcibly sets things up for the "official" local time zone
of the machine.  That minimizes the changes needed to fix things like

This also obviates the need for an application to smash both "TZ" and
"TIMEZONE" if it wants local time; "localtzset()" would do whatever is
necessary, and the application wouldn't have to know what was necessary.

The rules would be:

	"localtzset()" would forcibly cause subsequent conversions to use
	local time.

	"tzset()", called by "localtime" and "mktime" would first check
	if "TIMEZONE" was present in the environment; if so, it would
	use that.  Otherwise, it would check if "TZ" was present in the
	environment; if so, it would use that.  Otherwise, it would use
	local time.

"TZ" looks like it would be a wart if it were put into the P1003 standard
(as opposed to a UNIX manual page, where people are used to seeing horribly
warty specifications).  However, if you leave it out, it would either have
to say that if "TIMEZONE" isn't set, it uses local time (if possible),
meaning that "TZ" can't affect its behavior, or would have to say that the
behavior if "TIMEZONE" is not set is implementation-dependent, meaning that
the current unacceptable S5 behavior (use Eastern Standard Time if "TZ"
isn't set) would be permitted.

More information about the tz mailing list