std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/05/86)
Date: Sun, 5 Jan 86 00:52:37 est
From: seismo!harvard!think!mit-eddie!barmar@sally.UTEXAS.EDU (Barry Margolin)
In response to Mark Horton's posting about time zones:
Multics has long had per-process time zones, and they are extremely
heavily used on systems which have users logging in from across the
country (or world, in some cases). Most of the people in my Cambridge,
MA office use a system in Phoenix, AZ quite a bit, and I am considered
unusual because I don't bother to set my time zone to EST.
One good argument for only having system zones that was made was about
software that makes critical decisions based on the time of day (the
example was a wrapper for uucico that makes sure the call isn't being
made during the day). The solution is for such programs to ignore
the TZ inherited from the caller, perhaps using a new system call
that gets the system-default time zone. We don't have this problem
on Multics because security decisions are either made in daemon processes
or in inner-ring subroutines, and per-process variables are actually
per-process per-ring, so the user's personalization generally doesn't
affect secure domains.
One apparent difference in time zone semantics between Unix and Multics
is the behavior of past/future times. On Multics, the time zone in which
a date/time should be converted to GMT is an INPUT parameter, defaulting
to the process' time zone; we do not attempt to determine whether DST
was in effect on the date being converted. We therefore have no need
for complex DST calculation at run time. Whether this is considered
right or wrong is mostly a matter of taste; I know of a other systems
that have chosen to dynamically determine DST. In general, a subroutine
for converting a time in a specified time zone to GMT is a useful
facility; for instance, to interpret Date fields in mai headers.
I have been thinking about WHY many systems try to determine the
DST state at a given time. This is because they only store the binary
form of the time in various system databases, and attempt to display
the user-relative time at which the event took place (for instance,
so that you can tell that it was very late when the user modified
a file, so the bugs are probably because he was tired). The "right"
way to get this effect would be to store the user's personal time zone
in addition to the binary time. Display routines would display the
time in the retrieved time zone, rather than trying to guess the appropriate
time zone. In the context of Unix standardization, this is probably
unreasonable, as it is not consistent with any existing version of Unix.
It also has the problem that it increases the size of times stored in
many system databases, which may be considered wasteful for the little
benefit that this approach provides.
Barry Margolin
ARPA: barmar@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmar
Volume-Number: Volume 5, Number 7