[mod.std.unix] TZ and TERM per process; V5N16

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/12/86)

[ Let me reiterate something that many people do not seem to realize:
UNIX has *always* kept internal time in GMT; that is not an issue.

Joe Yao's summary below covers most of the actual issues.
If you do not agree with parts (or all) of it, submit your comments.
But no flames please.  This is a technical discussion newsgroup,
not a boxing ring.  -mod ]

Date: Sat, 11 Jan 86 15:08:53 est
From: seismo!hadron!jsdy@sally.UTEXAS.EDU (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA

Following this discussion, it is clear that a number of different
things are needed.  We need:
(1) a way to be sure that logs are kept in one, single, system-
    appropriate time;
(2) a way that people can set times reported to them to be meaningful;
(3) a way that people can enter times in a way that is meaningful to
    the system, but also understood correctly by the machine (with at
    or cron or remind as cases in point);
(4) a standard for individual machines to tell (over nets) other
    machines what time they think it is;
(5) perhaps an 'rtime' facility, to know what time it is elsewhere?;
[ Much work has been done on 4 and 5.  I will post a followup article.  -mod ]
(6) a way to be sure that processes can't override system time limits
    by changing the time (such as with UUCP);
(7) a way for system managers to be able to specify either a default
    "time zone" or a way of figuring out (from 0 to infinity) what
    the time really is/was.
Probably several other things, as well.

It's not clear that only one mechanism will take care of all of these.
For instance, agreeing to allow a time zone specifier in input formats
certainly addresses a lot of these.  But, what about "Pothole IL Local
Standard Time" (EST+0:04:17)?  We will need some way to figure out time
zones that are not exactly integral hours off from UCT.  I don't like
particularly the idea of user-written time agents, partly because I
know how often "professional software engineer"s make little (or big)
mistakes, especially in the area of not testing all boundary
conditions, and I can imagine those who aren't constantly engineering
software might make even more.  Perhaps we can figure out a way to
specify the rules for a time zone in a user-writable table, so that
if politicians decide to mess us up even further we can just send a
few lines of table over the net to patch the algorithm.  Note that
the algorithm  s h o u l d  work "from 0 to infinity."

[ It should also work from zero to negative infinity.  -mod ]

							And, of course,
each process group (or maybe process) might want to have an idea of
what its own expression of time is; but should be able to get at the
system's idea, too.  (Just for Rob Pike, a date -[lsv]?)  As an under-
lying time, of course, it is good to get machines to think and talk
to each other in UCT (GMT), as radio operators do, since that is one
of the things it was invented for!

[ Once more:  internal (kernel) UNIX time format is GMT, and that's also
what has always been used on networks like the ARPANET for communication
between systems, whether UNIX, TOPS-20, Multics, or whatever.  -mod ]

					It is (so far) independent of
astronomical or political changes in the "real" time.  We'll see how
this works once we start talking in terms of relativistic distances
[;-)].

[note: deference to rob pike, whose talk "cat -v considered harmful"
was actually a good expose' on creeping featurism.  -jsdy-]

[ The talk of that name was originally given at the Toronto (Summer 1983)
USENIX Conference and has an abstract in those proceedings.  A paper in
the same vein is:

          Pike1984.       R. Pike and B. W. Kernighan, "Program Design
                          in  the  UNIX  Environment," [BLTJ1984], pp.
                          1595-1605, 1984.

That journal issue is now selling for a reasonable price, I hear.
(I don't know what the price is or what the telephone number is.)

          BLTJ1984.       BLTJ,   "The   UNIX   System,"   AT&T   Bell
                          Laboratories Technical Journal, vol. 63, no.
                          8, American Telephone and Telegraph Company,
                          Short Hills, N.J., October 1984.

And if you like the article, you'll love the book:  :-)

          Kernighan1984.  Brian W. Kernighan and Rob  Pike,  The  UNIX
                          Programming    Environment,   Prentice-Hall,
                          Inc., New Jersey, 1984.

-mod ]
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}

Volume-Number: Volume 5, Number 16