Conversation with Ron Tolley
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
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 this is a total non problem. If old programs are going to dump core when given such an environment, then they will dump core now when given the same thiing. Its important to remember here that no-one is proposing requiring anyone to use a TZ environment string like that. If (for any reason at all, including having old binaries that you can't upgrade) a system prefers to use settings like TZ=EST5EDT then fine, they can. Just please don't require such strings. instead use some new environment variable--for example ZONE=US/Eastern No, please, we have an environment variable now for timezone info, there is no need to alter it (it might be shorter than some people would prefer, but that's a consideration to use when you're inventing a new name, its too late for that now). This would be a disaster. e. Throw caution to the wind and set things up so that TZ=US/Eastern is used (a possibility that Ron Tolley dislikes). This isn't what was proposed really. What's proposed is that what goes in TZ is an implementation issue (or even more correctly a local site issue). Legal values for that string need not be specified. Nor need illegal values. This is just like TERM - what values make sense vary from site to site, and what's more there's no guarantee that the same value means the same thing at different sites (a good example is "vt100" which seems to mean almost anything that looks roughly like an ansi terminal, and which happens to exist locally). 2. Ron noted that H-P's approach to getting guaranteed local wall clock time is to use the 4.?BSD "gettimeofday" call. As Guy said (more politely), this is nonsense. gettimeofday is GMT. The rest of what gettimeofday returns is exactly what we are trying to get rid of, as there's no way to do that properly. The H-P approach does have a real backward-compatability advantage. ... If, on the other hand, I write code that calls gettimeofday(); ... Very true, except gettimeofday() is entirely the wrong function. This is why settz() was *right*. It was a new function name for new (essential) functionality. One possibility I'd see: drop the demand that local wall clock time be used if TZ is absent from the environment, Please no. Doing the right thing when TZ is absent isn't so much for programs that want local time right (there just needs to be some mechanism for that, what the mechanism is isn't crucial). Its so that when TZ is absent, the most reasonable and desireable behaviour occurs. TZ *WILL* be absent! Finally, while I don't think all of the list saw the latest HP proposals, they look much more reasonable (excluding any comments about the X3J11/Xopen extensions). If I was doing it I'd complain a little about a few minor points (like the wording of the paragraph that says that the value of TZ can't be any random string with useful results) but there's nothing of any importance in there that's not OK. There are a couple of things missing though. One is that there is no mention of when the value of TZ is examined. The man pages imply that it will be on every call of localtime, which is contrary to the way Sys V does things now (and that might break some code, possibly). However the pages don't actually say that. This is important, and needs to be made clear. I would like to see settz() come back officially. This gets round the above problem (settz() is what examines the value of TZ, and localtime calls settz() exactly once, provided the user hasn't called it prior to calling localtime()). It also provides a nice clean implementation of a method to allow processes to decide what timezione they want to run in. For example - I would like to be able to write code that can call localtime in any random zone I choose. I already have a program that does that (at the minute it uses some absolutely gross hacks, and the 4.2 scheme, and its nothing like perfect). The purpose of this program is to tell me what time it is .. anywhere I choose to know it. Given a way to set the timezone, this is trivial. I also like to know several places in one invocation of the program. If the way to do this is to just have the program stomp on TZ, then that implies that localtime must be *required* to examine TZ at every invocation, and that is going to get slow, quite quickly (it will probably rule oout all the external file methods). So, there needs to be something to tell localtime when it needs to reexamine TZ. Or some other method of achieving the same result. ie: settz(). As I see it, ado's original design for all this was just about as close to perfect as any design I've ever seen (there were a few things that have been fixed in the implementation, but the design was great). Can't we just have it back that way? I also note, that if an implementation decides that the right way to do zone stuff is by stomping on TZ, then an settz() becomes settz(str) char *str { putenv("TZ", str); tzset(); } which makes it all VERY compatible with current Sys V. Implementing settz that way should be a local matter though. kre
participants (2)
-
ado -
Robert Elz