No subject

[Robert Elz]

    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