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