std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/04/86)
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