🚀 go-pugleaf

Date: Fri, 3 Jan 86 09:52:13 est
From: harvard!encore!babel!ptw@sally.UTEXAS.EDU (P. Tucker Withington)

In Mark's comments about time zones the only "insurmountable" problem he
found with the Sys III method was his security hole, that a user could
force uucp's L.sys table to be interpreted incorrectly.

The real problem is that the L.sys entry is ambiguous, unless a TZ
is given to interpret it.  The solution here is akin to having "init"
set a default time zone.  uucico needs to have a profile that defines
the timezone L.sys is to be interpreted relative to, which overrides any
user setting of TZ.  Alternatively, the L.sys entries could be "fully
specified", including a time zone or defined to be GMT.

The objection to putting TZ in the environment is not specific to TZ,
it is a general problem with the implementation of environment.  (There
probably should be some shared environment, in addition to private
environment, so that "constants" like TERM and TZ are not carried around
as excess baggage by each process.)

I conclude that the System III time zone mechanism is then equal to the
V7 mechanism, with the advantage that each user can operate in whatever
time zone he likes.

Regarding the daylight savings bugaboo:  I feel this is a red herring.
You probably care when the present time is DST, but being off by +/-
1 hour on ancient file dates is not going to really bother anyone.  Thus
it is probably sufficient to have a shell script in your profile to set
any "exceptional" DST times.

Volume-Number: Volume 5, Number 5