> From: seismo!cuuxb!dlm (Dennis L. Mumaugh)
> Subject: Default timezone
> 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. 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.
What "problems" does setting TZ to the local time zone (which *IS* PST here
where we do *our* development) disguise, and why does defaulting to GMT if
TZ is missing or empty reveal them?
> Using wall clock as default merely propogates this development
> problem and results in products having problems when they are
> used in other environments.
So does setting TZ in "/etc/init". The only way to flush these problems out
before the product is released is to *deliberately* run it with timezones
other than the developers' zone.
> From: seismo!cuuxb!dlm (Dennis L. Mumaugh)
> Subject: Re: Parsing /etc/TIMEZONE
> I do like the idea of a single place for establishing the TZ for
> a system. It makes it very easy for new administrators.
Olson's scheme has this, as well; you just use the "-l" flag when running
"tic". It causes a link name "localtime" to be made to the time zone
specified as the argument to "-l".
> Another problem with a routine to read and parse /etc/TIMEZONE is
> what does one do for non-ATT shells (c shell and others) the
> setting of TZ in the environment differs. That's why having
> /etc/init set things up is good. That guarentees a "standard
> environment". It is true someone could diddle with it, but I am
> more concerned with naive users than others.
You're going to need a routine to read and parse "/etc/TIMEZONE" anyway.
"uucico" will have to use it; it does NOT want to use "TZ" to indicate what
the local time zone is, precisely *because* somebody could diddle with it.
> From: Robert Elz <seismo!munnari!kre>
> Subject: Re: Default timezone
> Date: Wed, 17 Dec 86 11:09:09 cst
> From: cuuxb!dlm (Dennis L. Mumaugh)
> Message-ID: <8612171709.AA08584@cuuxb>
> The issue here really, is how does a programmer exercise his
> "conscious choice" to get 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.
Actually, any scheme would require you to find all the processes that
understand this, and insert some code to ensure that the machine's time zone
is used.
> 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.
Absolutely. This could be done in the S5R3.1 scheme, by providing a
function to read "/etc/TIMEZONE". You could even call this function
"settz()" (see below).
> 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...)
Do you mean "local wallclock time" or "local conversion rules"? With
current UNIX interfaces, and with all the proposals that have popped up so
far, all you could do is get the latter and use them to convert the result
of "time()" to local wallclock time.
> 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,
The S5R3.1 scheme does handle this, by having "init" put the time zone in
its environment.
> 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.
Actually, "settz()" could be implemented in the S5R3.1 scheme. Assume that
the time conversion code takes some string and uses it to set up the
conversion rules (details deliberately left unspecified). "tzset" would use
the value of 'getenv("TZ")' for this string. "settz" would do the following:
if its argument is a null pointer, read "/etc/TIMEZONE" and use
the string located therein;
if its argument is a pointer to a null string, use GMT;
otherwise, use its argument as the string in question.
There is one issue here; should a process only be able to affect how its
UNIX time <-> local time conversions are done, or should it also be able to
affect any children it spawns? The former is effected by "settz"; as it
stands, the later requires you to change TZ, either by eliminating it,
nulling it out, or setting it from "/etc/TIMEZONE". "uucico" would probably
want to affect its children; some other program might not.
I do have another question; are we discussing UNIX or POSIX here? If the
latter, should POSIX require that anything be supported other than local
machine time? It may be convenient to permit users to specify other time
zones, but user convenience is somewhat outside the scope of 1003.1, at
least.
POSIX should not *preclude* a user overriding the default time zone, and as
such must provide a way for a process to override the user's override and
get the default timezone; it probably must also provide a way to force its
children to use the default time zone, as well.
For this, all you need is a function that says "set time zone to the
default"; the full generality of "settz" isn't necessary. You could have
POSIX just define the behavior of "settz(char *)NULL)" and leave the rest up
to the implementation.
POSIX must also require that an application must, by default, get some
"reasonable" time zone information, which would either be the system default
time zone or, if supported, a user-specified time zone. It must do so in
such a way that no application need explicitly set up anything (such as
snarfing the right value of TZ from "/etc/TIMEZONE") in order to get this
information, and in such a way that no application need be run in a special
environment (i.e., saying "the way you set it is to put it in "/etc/profile"
is out).
Olson's scheme provides most of what is needed from the POSIX standpoint.
"settz" could be added to the S5R3.1 scheme, and it would be equivalent
(from the program's standpoint) to Olson's scheme. Both Olson's scheme, and
the S5R3.1 scheme with "settz" added, would provide a way for a program to
explicitly choose a particular time zone (and it would work in the same
fashion in both schemes), and would use the value of TZ if one was provided.
Both schemes make it simple for an administrator to set the default
timezone; in Olson's scheme, you just run "zic" with the "-l" flag
specifying the default zone, or make the link yourself, and in the S5R3.1
scheme you just set the "/etc/TIMEZONE" file.
Neither scheme directly addresses the question of "how do you teach your
children about the time zone you selected"? One way to do this would be to
use "putenv"; however, that exposes various implementation details that
really should not be exposed. Perhaps there should be a function like
"settz" that propagates that change to children.
