Default timezone

[Guy Harris]

	I mean local wallclock time (conversion rules out of an instruction
	would be a little wierd...  but this processor has a "load.time"
	instruction, or something like that, which returns local wallclock
	time, 64 bits, high precision, and lasts forever...)

By "local wallclock time", do you mean local wallclock time (DST and all),
or just the number that it was originally set to at time T plus the number
of clock ticks since time T?  If it's the latter, it could just as easily
keep "UNIX time".

	The time system call (I can't remember now if its in the kernel or
	not or if time(2) just does this in each user's code) gets that value
	and then applies basically the reverse transformation of localtime()
	to get GMT to return to the user...

	My point was that the method of discovering what local wall clock time
	is shouldn't be constrained at all in the standard.

But in most cases you get wall clock time by doing "time" or "gettimeofday"
and feeding that to "localtime"; if you do that on this machine, and it's OS
is really UNIX-compatible, the fact that the hardware keeps some flavor of
local time is irrelevant.  The application would get "UNIX time", and then
call "localtime" to convert that back to local time in some time zone.

The standard *already* constrains the way you discover what local wall clock
time is; you get "UNIX time" from "time" and feed it to "localtime".
Hardware that keeps "wall clock time" is, in a POSIX system, an obstacle to
overcome (you have to convert "wall clock time" to "UNIX time") rather than
something that makes certain operations easier.

If you really don't want the standard to constrain how you get local wall
clock time, you'd have to add a function like "localtime" that takes *no*
arguments, and returns the broken-down value of the wall clock time, or add
a function like "time" that returns wall clock time as a "time_t" and use
"gmttime" or something if you want to break that down.

	    The S5R3.1 scheme does handle this, by having "init" put the
	    time zone in its environment.

	No, that only gets it to the children of init, and their children,
	until someone types "env - sh" to their shell...

How is typing

	env - sh

to your shell different from typing

	TZ=Europe/Albania; export TZ

to your shell?  In either case, the user is explicitly reaming out their
environment.  Are you saying that even if a user reams out their
environment, programs they run should get local time by default?  I neither
agree nor disagree with this; I haven't seen what I consider to be a good
argument either way.

	    Actually, "settz()" could be implemented in the S5R3.1 scheme.

	Yes, the problem is whether AT&T will do it or not.

Since some way of permitting a program to get all time conversions to be
done with the "official" local rules is required, the standard must include
something like that.  The S5R3.1 scheme already has a way of doing it; you
open "/etc/TIMEZONE", read it, and "putenv" the value in there.  However, 1)
you don't want to have to write the same idiom 500 times for 500 programs,
and 2) you want the standard to have a way of requesting "official" local
time without having to know so many details of how the rules are specified,
so that the standard doesn't have to require you to use TZ and all the
baggage (i.e., the ability for the user to choose which rules they want)
that this drags in.

So you want some way of saying "please give me local rules", rather than
some way of getting the "name" of the local rules and some way of saying
"please give me this set of rules".  "settz((char *)NULL)" seems fine to me.
(The behavior when "settz" is passed a string rather than a null pointer
could be left up to the implementation, in case any implementor might object
to a fully general scheme.)  If the standard does include that, AT&T could
implement it, and would have to if they wanted to sell to somebody who
required POSIX compliance.