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