Alto_Time_Standard_Feb78.pdf part of xerox Alto Time Standard Feb78 Alto_Time_Standard_Feb78.pdf, xerox alto memos_1978 Alto_Time_Standard

Text preview for : Alto_Time_Standard_Feb78.pdf part of xerox Alto Time Standard Feb78 xerox alto memos_1978 Alto_Time_Standard_Feb78.pdf

Back to : Alto_Time_Standard_Feb78. | Home

Inter- Office Memorandum

To PARC/SDD Date February 26, 1978

From Ed Taft Location Palo Alto

Subject Alto Time Standard Organization PARC/CSL
(Edition 3)

XEROX
Filed on: AltoTime.Ears, .Press, AltoTime.Bravo

I am resurrecting a proposal I made nearly two years ago to change the Alto's internal date
and time standard. The need for this change has become more pressing since that time, so I
would like to see it accomplished as quickly as possible.
A number of software systems will be affected by the change. This memo attempts to
enumerate them, but I have undoubtedly missed some (particularly ones in the Mesa and
Smalltalk worlds). Fortunately, the consequence of failing to convert immediately is not
catastrophic.
The last section of this memo sets forth a schedule for converting from the old standard to
the new. My intention is that the conversion be relatively smooth and that old programs
continue to work until such time as support for the old standard is revoked.
Change since Edition 1: The internal representation of a time zone is entirely different so
as to accomodate fractions of an hour and other oddities.
Change since Edition 2: Current status.

Present Standard
The current Alto time standard is a 32- bit integer denoting the number of seconds since
midnight, January 1, 1901, local time (with Daylight Savings Time already applied if it's that
time of the year). This standard has two important difficulties.
First, it is location- dependent: a given 32- bit integer represents a different absolute time
depending on the time zone within which it is interpreted. With the proliferation of Altos
across many time zones and the certainty that they will eventually be able to communicate
with each other, it becomes desirable that a time standard be location- independent. Given
this, a host in one time zone may obtain the current date and time (as a 32- bit number)
from a host in another time zone, without either host having to know the location of the
other. This capability is needed now because Webster has just been connected to our present Parc/SDD/XEOS
inter- network.

Second, the present time standard is not monotonic: it jumps forward an hour in April and
backward an hour in October so as to conform to daylight and standard time. Hence an
Alto's clock cannot be maintained correctly simply by counting milliseconds, and for this
reason it is not maintained correctly at present. Furthermore, there is a two- hour stretch of
absolute time every October within which each 32- bit number is used twice. The
Alto Time Standard 2

monotonicity of time on a single machine is vital to the correct operation of programs such
as the Maxc and IFS backup systems.

New Standard
The new time standard is similar to the present one, but it uses GMT (Greenwich Mean Time)
as a basis rather than local time. The choice of GMT is arbitrary, but it is the one adopted by
many computer operating systems, including Tenex.
Precisely: the internal time standard is the number of seconds since midnight, January 1,
1901, GMT, represented as a 32- bit integer. Clocks maintained according to this standard will
have the same value at any given instant of absolute time, anywhere in the world.

Local Time Conversion
With adoption of this time standard, responsibility for applying time zone and daylight
savings time corrections is shifted into the software that converts between internal and
external representations. Fortunately, these corrections are relatively simple. In order to
perform conversion between the GMT standard and the local external representation, such
software needs three pieces of additional information. These are the local time zone (time
east or west of Greenwich), the day of the year on or before which daylight savings time
takes effect, and the day of the year on or before which standard time is reinstated (these
days are adjusted to the next earlier Sunday).
These quantities are quasi- constant, in that the local time zone changes only when a machine
(or a disk pack containing the software) is moved into another time zone, and the DST
starting and ending dates change only when Congress sees fit to change the applicable laws,
as it did a few years ago during the oil embargo. However, the probability of these or
similar events is sufficiently high that it would be a mistake to build the parameters into the
software as constants.
The requirement, then, is to maintain and distribute local time correction parameters in as
automatic manner as possible. This is accomplished by the following strategy:
1. The parameters are maintained permanently in server hosts (Gateways, IFSS,
Maxcs, etc.) that are always up and never move. The numbers are "wired- in" in a
manner requiring manual intervention to change.
2. Such hosts have time servers that give out the local time parameters as well as the
absolute time (GMT) upon request by a host on a directly- connected, geographically
restricted network. It is assumed that no single Ethernet spans multiple time zones. Gateways
whose interconnections do cr'oss time zones have to know that they must not believe each others' local
time parameters.

3. Each Alto maintains these parameters in reserved locations both in main memory
and on the disk. Whenever a time server is accessible, the Alto updates the local
parameters with the information provided by the server.
The purpose of keeping the local time parameters in each Alto in a relatively permanent
form is to ensure their availability (with a high probability of correctness) if not obtainable
. from other sources. A user of a stand- alone Alto (one not connected to an Ethernet, or
whose Ethernet is down, or whose local time server is down or nonexistent) would justifiably
be annoyed if every time his Alto "forgot" the time he had to enter the local time zone and
DST parameters in addition to the actual time.
Alto Time Standard 3

Implementation Details
The UNPACKDT and PACKDT procedures in the "Time" software package have been modified
to perform corrections for time zone and daylight savings time. They may be used as models
for converting other software that performs similar operations. Note that the corrections are
applied during the transformation between the "packed" and "unpacked" internal time
formats; no special processing is necessary during the transformation between the
"unpacked" format and text strings. However, an option has been added to append the time zone to the
text string format so as to permit location- independent processing of it. This is important, for example, in the
time stamps included in DMS message headers.

This new version of the "Time" package operates correctly only under as version 14. If you
are responsible for any software that deals with time conversion or printing, you are advised
to examine carefully the revised documentation in [Maxc1] Time.Tty and
possibly the revised source code in the dump- format file TimeSource.Dm.
Two new procedures are added to the Operating System: ReadCalendar and SetCalendar.
They are analogous to the existing DayTime and SetDayTime procedures except that they
deal in GMT rather than local time. The reason for adding new procedures rather than simply redefining
the existing ones