std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/09/86)
Date: Thu, 9 Jan 86 11:39:06 est
From: Davidsen <seismo!rochester!steinmetz!davidsen@sally.UTEXAS.EDU>
Organization: GE CRD, Schenectady, NY
The recent posting on TZ implementation has prompted discussion at our site,
with the following comments and suggestions:
1) Process TZ is very useful. We use systems in Chicago and Minn, and would
like our times as displayed to be meaningful. We regularly reset TZ in our
.profile on these systems.
2) An extension is needed to handle cases where the TZ offset is not an even
hour, and where the daylight savings time calculation is not the (current) US
standard. We even were so bold as to envision one method of doing this.
The proposed solution is to give a TZ value having no offset, simply a series
of characters as the identifier, as "TZ=PILST". When a TZ without an offset
was located, a directory would be searched for a file with the same name. For
illustration, call this /usr/bin/TZ. When the matching file was executed using
the date for an argument, the correct offset from GMT would be returned in
clock ticks. This value could then be added to the current GMT value to get
"process local" time.
Note: what is important
is that the processes are user (sysmgr) definable to match changing local
laws, etc. I would feel that it is acceptable to require reboot of the system
to change these procedures, so some pointers or even the process itself(?)
could be kept in memory to speed things up.
These routines would have to be executed fairly often, since the
change points of the algorithms might be anywhere. Another suggestion was to
make these routine devices, and install them as device drivers.
The example time zone, PILST, stands for the hypothetical "Pothole IL Local
Standard Time", which is 4:17 ahead of the rest of the state because the clock
in town hall is off by that much. This example is less funny if you look at
the number of entire countries in conventional time zones, particularly those
shared by Eurasia and Africa. Hospitals might want to shift the change to
daylight time by some hours to minimize the posibility of error, and could,
using this solution, have their own "hospital standard time".
The problem of time for uucp and at are not as simple as they seem. If I want
to run a job during off hours, 0100 means 1am, computer time. If I want to
have the system call me back at 3:30pm local time to test a new uucp or
something, I mean my local time. If I make a cron entry to run uucico at a
given time, it uses the default shell timezone, while incoming calls use the
system, since the are not executed under a shell. This confuses the logfiles
no end. One of our sysmgrs keeps the system time at GMT rather than EST5EDT
(for valid reasons, but complex), which really messes up the log. I think the
solution to that would be to have uucico use some known TZ rather than the
inherited TZ (/usr/lib/uucp/TZ anyone?). This would keep the logs consistant.
Obviously the times in L.sys should be to a standard, but should it be local
time or destination time. Since the anther is "both", a TZ field may have to
be added to L.sys, since local time is what I use to control my phone bill,
but destination time is what I use if a remote system is only up for uucp at
certain times.
Hopefully these ideas will inspire some constructive followup.
-bill davidsen
seismo!rochester!steinmetz!--\
/ \
ihnp4! unirot ------------->--- crdos1!davidsen
\ /
chinet! ---------------------/
"It seemed like a good idea at the time..."
Volume-Number: Volume 5, Number 13