Default timezone

[Robert Elz]

    Date:        Wed, 17 Dec 86 11:09:09 cst
    From:        cuuxb!dlm (Dennis L. Mumaugh)
    Message-ID:  <8612171709.AA08584 at 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