TZ Rationalization Requested

[fair at dual.UUCP]

I have a bone to pick with the folks who decided to change the way
UNIX keeps track of the timezone in System III and System V. For those
fortunate enough to be using 4BSD or V7, I will explain.

In Version 7, the timezone was kept in a variable in the kernel, in the
form of the number of minutes westward of GMT. There was also a flag that
indicated whether daylight savings time applies in the timezone.

In System III, this changed to keep the hours westward of GMT, along with
the DST flag in an environment variable, dubbed `TZ'. The following
string is in my TZ variable:

		PST8PDT

This says that my timezone is called `PST', and I'm 8 hours west of GMT,
and that daylight savings applies, and is called `PDT'.

The fact that it is in an environment variable now makes life difficult
for programs that are spawned from /etc/init (e.g. getty), and the SA's
have to remember to add TZ=PST8PDT; export TZ to the top of their /etc/rc
file. Login has to be fixed to either get it from some file, or try and
find it in the enviroment passed to it (where it won't be, since init
doesn't have an environment, and init spawns getty).

But the two most objectionable `features' of this implementation are

	1) To make the TZ `take', you have to call tzset();
	2) The default timezone is EST.

The effect of #2 is that you don't notice you didn't do #1, when you're
in New Jersey. So there's lots of UNIX software that's broken, when you
move it west (or east!) of EST. The end result is that I (and others, no
doubt) have spent, and will spend lots of time cleaning up after this
re-implementation of timekeeping.

Now, the thing *I* want to know is:

	Why the guys at USG decided to do things this way?

The most credible argument I have heard is that if you're logged
into a system in another timezone, you want your mail stamped with the
timezone you're in, and when you fire up `date', it will give the time for
your timezone, rather than the computer's. Or at least you want this
capability.

Has anyone else heard a better reason to do it this way?

	Erik E. Fair

	dual!fair at BERKELEY.ARPA
	{ihnp4,ucbvax,cbosgd,decwrl,amd70,fortune,zehntel}!dual!fair
	Dual Systems Corporation, Berkeley, California