Conversation with Ron Tolley

[Arthur David Olson]

Ron Tolley of Hewlett-Packard called Friday.  I'd like to relay a couple of
points Ron made (points which may or may not reflect official corporate policy
of H-P, blah blah blah), add some notes of my own (notes which may or may not
reflect official policy of the National Institutes of Health, blah blah blah),
and ask for comments.

1.  Setting up "new" time zone handling software to deal with environment
    variables such as
	TZ=US/Eastern
    may make for problems when running "old" executables that expect the
    TZ environment variable to be of the form
	TZ=EST5EDT
    where, depending on the quality of an implementation,
    "problems" here can range anywhere from getting core dumps to
    getting incorrect results.

    As others have noted, staying strictly with the current System V
	TZ=<standard abbreviation><offset from GMT><daylight abbreviation>
    system can't work--for example, with
	TZ=EST5EDT
    there'd be no way to tell whether a user wanted Canadian or US Daylight
    Saving Time rules applied.

    The possibilities I see:

    a.  Continue to demand that the TZ environment variable be of the form

	TZ=<standard abbreviation><offset from GMT><daylight abbreviation>

	(a possibility I'd dislike).

    b.  Set things up so that, for example
		TZ=EST5EDT
	asks for US rules to be used while
		TZ=Est5Edt
	asks for Canadian rules to be used--although either of the above would
	"EDT" to be used in the output of date(1) and such.

	This will, of course, meet with the disapproval of those who think
	case sensitivity in UNIX is a bad thing.  :-)

    c.  Set things up so that the TZ environment variable is of the form
		TZ=EST5EDT
	and so that a new environment variable such as
		TZTYPE=Canada
	tells the type of time zone rule to be applied.

    d.  Set things up so that instead of setting
		TZ=US/Eastern
	you instead use some new environment variable--for example
		ZONE=US/Eastern
	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 wants.

	(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.)

    e.  Throw caution to the wind and set things up so that
		TZ=US/Eastern
	is used (a possibility that Ron Tolley dislikes).

	My current leaning would be toward possibility 'd' above--with careful
	documentation of tzset's habit of looking for ZONE and then TZ.

2.  Ron noted that H-P's approach to getting guaranteed local wall clock time
    is to use the 4.?BSD "gettimeofday" call.  This contrasts with approach
    demanding that local wall clock time be returned by "localtime" if
    there's no TZ environment variable.

    The H-P approach does have a real backward-compatability advantage.
    If, in trying to ensure that I'm going to get wall clock time, I write
    code that zaps TZ from the environment and then does
		tzset();
    and
		localtime();
    calls, the code will happily compile and run on existing System V systems--
    and may give wrong results.  If, on the other hand, I write code that
    calls
		gettimeofday();
    the code won't compile at all on existing System V systems.  The bad
    news is that I won't get any results at all; the good news is that I
    won't get wrong results.

    One possibility I'd see:  drop the demand that local wall clock time be
    used if TZ is absent from the environment, and add a function such as
		walltime()
    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".

				--ado