Date: Wed, 17 Dec 86 11:09:09 cst From: cuuxb!dlm (Dennis L. Mumaugh) Message-ID: <8612171709.AA08584@cuuxb> Our reasoning is that in the majority of cases this is an error by the system administrator in setting or exporting the TZ variable and it is necessary for someone to notice the error. Yes, you might be right. But there is NO way that the system administrator can prevent users setting TZ to whatever they like. Its a *user* parameter, not a system one. There are VERY good arguments, I think, for not putting any system information in the environment, ever (that includes LOGNAME, TZ, ...). The environment should be used by users to tailor their personal setup (TERM, SHELL, TZ if they want different than the default, etc). As it stands most developers/porters set the TZ to their local time zone (who is it that uses PST?!) and then never notice that their product has problems. Yes, this is a very definite problem. But notice that what is being suggested is that when TZ is missing localtime where the host is situated must be provided. Not localtime where the port was done. Doing that correctly is much harder, and certainly something that any developer is going to test in a few different zones (or by simulating a few different zones). That is, simply compiling in some value is *guaranteed* to be incorrect. What's more, given a suitable implementation from AT&T, there would be no need (or incentive) at all for the majority of porter's to ever go near this piece of code. Its only because Sys V used to compile in EST5EDT (which is wrong in California, and almost everywhere else) that developers touch this code at all. The use of wall clock as the "default" ought to be a concious choice by a programmer and GMT ought to be the default whenever a time routine can't decide what timezone to use. Yes, that's reasonable, if things are so screwed that a process can't figure out what the local time is, then GMT is a reasonable choice for a default. Mostly because its easy... It doesn't really solve the problem of developers not noticing the error, there are developers in the UK you do realize? From that point of view, having localtime() use some completely absurd timezone (or simply return NULL) might be better. But this would probably break too much code which assumes that localtime() cannot fail. The issue here really, is how does a programmer exercise his "conscious choice" to get wall clock time? In the current AT&T model, there is simply no way that a programmer can do that, all he has is TZ, and whatever that happens to be set to, which might be anything, or GMT. Where does he find wall clock time? If you wanted to define /etc/TIMEZONE or something as a file containing the right TZ string, so that programs that need wall clock time would be required to go read (and parse) that file, then that would be a solution. But you had better be prepared to define the format and name of that file, and stick to it forever more. You should also be prepared to go and find all the standard processes that need this (like uucico, and others) and insert the relevant code. Personally, I prefer a slightly simpler interface. That doesn't preclude putting the information in a file, of whatever format you prefer, but it should be the time functions that read the file, not the user's code. This also allows for more implementor flexibility, she has lots of choices she can make as to how to obtain the local wallclock time - from a simple ascii file, from a precompiled binary file, from a network information server, from the kernel via a system call, and I assume lots of others. I can even imagine processors where local time might be available as an instruction in the instruction set (I can imagine such processors because we have one...) What's needed then is a standard way for the programmer to make his conscious choice to use wallclock time. General opinion seems to be that doing this when TZ is not set is the right way to do it. If you have some better method to suggest then I'm sure we'd all like to hear it. Certainly having local wall clock time be the default when TZ is not set is a very sensible way to do things, as it means that the system administrator doesn't need to set up TZ for every process in the system, and then worry what happens when some process unsets it. And there's no need for every process in the system to carry around this extra baggage. Variables in the environment do cost - execs can get quite a bit slower as the environment grows. Most of the people on this list seem to feel that the right way for a program to choose wallclock time explicitly, is to putenv() TZ to a null value. Personally, I still think settz() is a cleaner interface. To sum up, your basic premise is mistaken. Its not an error to fail to set TZ, that should be the normal case... Robert Elz seismo!munnari!kre