Text preview for : 19771123_Time_Of_Day_Facilities_In_Pilot.pdf part of xerox 19771123 Time Of Day Facilities In Pilot xerox sdd memos_1977 19771123_Time_Of_Day_Facilities_In_Pilot.pdf
Back to : 19771123_Time_Of_Day_Faci | Home
To Pilot Interest Date November 23, 1977
From H. C. Lauer Location Palo Alto
Subject Time Of Day Facilities Organization SOD/SO
in Pilot XEROX SDD ARCHIVES
I have read and undel.'stood
XEROX Pages ____-----TO ---------
Reviewer Date~.-------
Filed on: TimeOfDay.memo # of Pag es _ __ Ref .11saD '38~
This memo describes our proposal for facilities for maintaining the time of day and date
within a system element. This proposal is predicated on the availability of a reliable,
battery-powered Time-and-Date clock in the hardware (in the form of a watch chip or
equivalent), and it is characterized by the separation of the time-of-day functions into
simple, uniform facilities provided by Pilot and facilities oriented to the human user
provided by some form of common software.
General Strategy
We propose that the clock in each DO processor maintain the time and date according to
Greenwich Mean Time. Pilot will implement an operation by which any client can get the
current time (GMT) and a private operation by which special programs can correct the time
in the case of clock drift, battery replacement, or repair of malfunction. The time will
probably be returned in the unpacked format described below (unless the packed format
turns out to be more convenient). Common software routines will be provided to convert
this value into values of the local time and date and into formats suitable for application
programs. These routines will also implement such features as Daylight Saving Time, which
depend upon the locality in which the system is installed.
It is the intention of this proposal that all values of the time and date stored internally
within a system element or transmitted over a network in a form intelligible to DIS
software be in Greenwich Mean Time. In particular, Pilot will use the Greenwich Mean
Time whenever it records the time, such as the creation date or last reference date for a file.
This convention will eliminate much confusion over the meaning of time-stamps and time
values communicated by machines scattered over the globe. It will, to a large extent, keep
the customer from having to set the time (and get it wrong), and therefore it will allow
applications to depend fairly heavily on having a meaningful, consistent value of the time
available on any particular system element. It will also allow us to parameterize our
software to accommodate local conventions about the official time without having these
considerations penetrate the applications themselves.
Note that although the timing facilities are expected to be very reliable and the watch chip
will record the passage of time very accurately, the absolute value of the time will not be
particularly accurate. I.e., this proposal does not provide a network-wide or universal source
of the time. I n particular, the clocks on system elements will gradually drift apart, and thus
a difference of a few seconds between events recorded by different machines cannot be
considered significant. However, the accuracy will be ample for events measured in human
terms.
Note also that this facility (or one based on it) would make a reasonably reliable unique
name generator for whatever purpose one is required. In particular, the probability is low
that a name (time-value) will be generated on a particular system element more than once at
intervals greater than the resolution of the clock. Similarly, the probability is high that a
malfunction which might lead to duplicate names being generated will be detected rapidly
because of the high user visibility of the time.
Data Formats
We propose that the time be represented in forms similar to those used by the existing Alto
Mesa timing facilities (see the module TimeDefs.Mesa). In particular, the packed format of
the time will be a 32-bit cardinal recording the number of seconds since an arbitrary base
time. Note that this counter overflows in approximately one century, so that January I, 1901, is not a suitable
base time for our product. The unpacked format is a record containing cardinals representing
the year, month, day, hour, minute, second, and possibly the day of the week and "time
zone." Because watch chips typically return the time in this format, Pilot will probably do
so also (unless we get a very strange one!).
Pilot Functions
Pilot will provide just two operations for time of day:
GetTimeAndDate:- Returns Greenwich Mean Time in the Unpacked format.
AdjustTimeAndDate:- Accepts an integer argument indicating the error (in seconds)
of the watch chip from the "correct" Greenwich Mean Time.
The operation GetTimeAndDate will be a public procedure available to all Pilot clients. The
operation AdjustTimeAndDate will be provided only to bona fide timer maintenance
software and will not be available to other clients. This minimizes the need of Pilot clients
to monkey with the time and hence the chance to get it wrong.
Common Software Functions
Common Software should provide at least the following facilities to support the time of day
clock:
Unpack DateAndTime:- accepts a value of the time in packed format and returns it
in unpacked format.
l~ackDateAndTime:- the inverse of UnpackDateAndTime.
GetLocaITime:- accepts a value in Greenwich Mean Time (packed format) and
. returns the corresponding value in local time, adjusted for Daylight Savings
Time, etc. (should it also take a parameter stating the "time zone" or should
this be derived from global data?)
GetGMT:- inverse of GetLocalTime (is this really necessary?).
AppendDateAndTime:- accepts two arguments, a string and an unpacked value of
time, and appends a printable representation of the latter to the former; this
might be subdivided into operations which separately append the date, time,
day of the week, and local "time zone" (such as EDT, PST, etc.).
WaitUntiiTime:- accepts an argument representing the Greenwich Mean Time at
which operation returns; i.e., the calling process is put to sleep until then.
Daylight Savings Time adjustments should be made automatically by Common Software.
I.e., the user should not have to perform a separate operation to set the clock ahead or back.
Furthermore, the adjustment should always be relative to the actual time being converted.
E.g., a GMT time stamp stored with a file of, say, 1200, July I, 1977, would be converted as
5:00 AM Pacific Daylight Time, independent of whether the conversion takes place in the
summer or the winter.
Installation Parameters and Multi-national Considerations
Because the processor maintains only Greenwich Mean Time, the Common Software
facilities must include an installation parameter to account for the local time and time zone.
These facilities must also reflect local and national conventions in presenting the time,
changing to Dayl ight Saving Time, etc. Thus, the following are the installation parameters
which must be settable by the Xerox installation representative (or possibly the customer
himself).
The AppendDateAndTime routine:- This must convert the date and time to a string
in the language and format of the customer; i.e., day first or month first, etc.
The local time zone.
A Daylight Saving Time adjustment routine, based on either an algorithm or a table.
The Base Time for packed format.
Setting the Time
Clearly, if the hardware time of day clock is going to drift, then the system must provide
some way of correcti ng it. Furthermore, the customer may also need to change the
relationship between his local time and Greenwich Mean Time (due to error, relocation,
change in law or custom, etc.). I suggest that these two problems are separate and should be
treated separately. In particular, the problem of the relation between local time and GMT is
treated the the previous sections.
This leaves the question of adjusting the hardware clock to compensate for drift, battery
failure, or malfunction. I propose that any facility along these lines be implemented as a
separate application program which is called only as circumstances require. There are a
number of different methods which might be used, depending upon the system configuration
and the options the customer is willing to buy. These include:
For stand-alone system elements, a program which asks the user to indicate how far
forward or back to adjust the clock.
For system elements on a Xerox Wire, a program which polls other system elements
and compares its clock with theirs. It sets its clock to the median (not the
mean) of the others if it is wildly different from them.
For Xerox Wires or other OIS networks which have one or more server machines
with clocks officially designated as "accurate," a program which checks the
local clock against the official clock server.
For those who need to know the time very accurately, a hardware device which
deri ves the national standard time from an external source.
For those who need to know it fairly accurately but only occasionally, a dial-up time
server maintained by Xerox, the phone company, or the government, and
which quotes the time in a standard digital format.
It is an option depending upon the customer's requirements and the system and network
configuration whether the time correcting program is run manually on demand or
automatically at preset times. It is an independent option whether or not it interacts with
the human user and asks for confirmation.
Distribution:
Lynch
Shultz
Liddle
Metcalfe
Stottlemyer
Wick
Irby
Kimball
Johnsson
Redell
McJones
Gifford
Horsley
Bishop
Rosen
Thacker
White
Dalal
Murray
Schwartz
Jarvis
Clark
Reber