Inter-Office MemorandumToPARC/SDDDateFebruary 26, 1978FromEd TaftLocationPalo AltoSubjectAlto Time StandardOrganizationPARC/CSL(Edition 3)XEROX Filed on: AltoTime.Ears, .Press, AltoTime.BravoI am resurrecting a proposal I made nearly two years ago to change the Alto's internal dateand time standard. The need for this change has become more pressing since that time, so Iwould like to see it accomplished as quickly as possible.A number of software systems will be affected by the change. This memo attempts toenumerate them, but I have undoubtedly missed some (particularly ones in the Mesa andSmalltalk worlds). Fortunately, the consequence of failing to convert immediately is notcatastrophic.The last section of this memo sets forth a schedule for converting from the old standard tothe new. My intention is that the conversion be relatively smooth and that old programscontinue 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 soas to accomodate fractions of an hour and other oddities.Change since Edition 2: Current status.Present StandardThe current Alto time standard is a 32-bit integer denoting the number of seconds sincemidnight, January 1, 1901, local time (with Daylight Savings Time already applied if it's thattime of the year). This standard has two important difficulties.First, it is location-dependent: a given 32-bit integer represents a different absolute timedepending on the time zone within which it is interpreted. With the proliferation of Altosacross many time zones and the certainty that they will eventually be able to communicatewith each other, it becomes desirable that a time standard be location-independent. Giventhis, 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 theother. This capability is needed now because Webster has just been connected to our present Parc/SDD/XEOSinter-network.Second, the present time standard is not monotonic: it jumps forward an hour in April andbackward an hour in October so as to conform to daylight and standard time. Hence anAlto's clock cannot be maintained correctly simply by counting milliseconds, and for thisreason it is not maintained correctly at present. Furthermore, there is a two-hour stretch ofabsolute time every October within which each 32-bit number is used twice. The]gp c8q]r-q7Br \q]r-q7Br VBq]r-q 7Br]T Osr IE C? BgP @9 =< /]Alto Time Standard2monotonicity of time on a single machine is vital to the correct operation of programs suchas the Maxc and IFS backup systems.New StandardThe 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 bymany 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 willhave the same value at any given instant of absolute time, anywhere in the world.Local Time ConversionWith adoption of this time standard, responsibility for applying time zone and daylightsavings time corrections is shifted into the software that converts between internal andexternal representations. Fortunately, these corrections are relatively simple. In order toperform conversion between the GMT standard and the local external representation, suchsoftware needs three pieces of additional information. These are the local time zone (timeeast or west of Greenwich), the day of the year on or before which daylight savings timetakes effect, and the day of the year on or before which standard time is reinstated (thesedays 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 DSTstarting 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 orsimilar events is sufficiently high that it would be a mistake to build the parameters into thesoftware as constants.The requirement, then, is to maintain and distribute local time correction parameters in asautomatic 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 amanner requiring manual intervention to change.2. Such hosts have time servers that give out the local time parameters as well as theabsolute time (GMT) upon request by a host on a directly-connected, geographicallyrestricted network. It is assumed that no single Ethernet spans multiple time zones. Gatewayswhose interconnections do cross time zones have to know that they must not believe each others' localtime parameters.3. Each Alto maintains these parameters in reserved locations both in main memoryand on the disk. Whenever a time server is accessible, the Alto updates the localparameters with the information provided by the server.The purpose of keeping the local time parameters in each Alto in a relatively permanentform is to ensure their availability (with a high probability of correctness) if not obtainablefrom other sources. A user of a stand-alone Alto (one not connected to an Ethernet, orwhose Ethernet is down, or whose local time server is down or nonexistent) would justifiablybe annoyed if every time his Alto "forgot" the time he had to enter the local time zone andDST parameters in addition to the actual time. frG bV `qr \ u Y'r'qr W2qr V1 S8W Qqr5 P.Q Ku Hr$3 G7K ET D-qr5 B= A#= ?F >. ;4M 96q 8*r3( 6> 5 [ 3 0K /1N,L7qr*;)B/&]W$qr(#Sq'%!J rCoB7 @ ,3 W v:" *1 lqr+ %>/WJAlto Time Standard3Implementation DetailsThe UNPACKDT and PACKDT procedures in the "Time" software package have been modifiedto perform corrections for time zone and daylight savings time. They may be used as modelsfor converting other software that performs similar operations. Note that the corrections areapplied during the transformation between the "packed" and "unpacked" internal timeformats; 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 thetext string format so as to permit location-independent processing of it. This is important, for example, in thetime stamps included in DMS message headers.This new version of the "Time" package operates correctly only under OS version 14. If youare responsible for any software that deals with time conversion or printing, you are advisedto examine carefully the revised documentation in [Maxc1]Time.Tty andpossibly 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 theydeal in GMT rather than local time. The reason for adding new procedures rather than simply redefiningthe existing ones to deal in GMT has to do with the transition from the old time standard to the new. This isdealt with in the next section.Two additional Alto main memory locations are reserved: 570B and 571B (thereby extendingby two words the region reserved for time-related information, presently 572B through577B). These cells contain the following information:570Bbit 0Zero if the local time zone is west of Greenwich, one if east.bits 1-4Local time zone in hours east or west of Greenwich. This is aninteger in the range 0 to 12. The Pacific time zone is 8 hours west ofGreenwich.bits 5-6Unused.bits 7-15Day of the year on or before which Daylight Savings Time takeseffect, where 1 = January 1 and 366 = December 31. Thesoftware will adjust this number to the nearest preceding Sunday.The standard value is 121 = April 30. The correspondence betweennumbers and days is based on a leap year. The software corrects for theabsence of February 29 during non-leap years.571Bbit 0Unused.bits 1-6Additional minutes east or west of Greenwich, in the range 0 to59. This is usually zero, but there are a few places in the world whose localtime is not an integer number of hours from Greenwich.bits 7-15Day of the year on or before which Daylight Savings Time ends.The standard value is 305 = October 31. If Daylight SavingsTime is not observed locally, both the start and end dates shouldbe set to 366.These new cells (like the existing time-related cells) must not be written into by any boot orcore-image restoration process.Copies of these cells are written into magic locations in the Operating System core image(Sys.Boot) by the OS "Install" procedure and by the SetTime subsystem. The locations usedare virtual addresses 1375B and 1376B, which actually reside at word addresses 775B and 776Bin the file due to the manner in which boot files are organized.When the OS is booted, it checks to see whether the local time parameter cells in main frG bu _9rqrqr* ]A \/^ ZA Y%-7. W#q6 V?] U, RAr.qr P] O7/0/ M#0 J-' IH< Gqrq& Fbn E% Bdr@/#@- 4@,uq@+*@)-'rqr@$1@"@"qJ@!K6r@0 @#@A@ O  6# 'qrF qrqrqrq r@ 8qr3 ?/]Alto Time Standard4memory contain reasonable values. Booting an old OS will set them to zero, which is invalid. If not,it restores them from the magic locations in the OS core image, which most likely have beenset to reasonable values by a previous Install or SetTime.The time servers on the Gateways and Maxcs are modified to accept a new type of timerequest and to respond with both the present time (GMT) and the local time parameters.Converting to the New StandardThe following is intended to be an exhaustive list of changes that must be made, in the orderrequired for a smooth transition from the old standard to the new.1. Release Operating System version 14, which maintains time according to the newstandard and that incorporates the new ReadCalendar and SetCalendar procedures.In this version of the OS, the existing DayTime and SetDayTime procedures aremodified to subtract or add 8 hours (respectively) to convert between GMT and PST.This temporarily permits existing, unmodified subsystems to continue to obtain localtime even though the OS keeps GMT. OS 14 has been released.2. The preceding step provides complete compatibility (I think) for all existing Bcplprograms except Bravo. Bravo does not use the OS DayTime procedure but rather hasits own copy of DayTime. Therefore, it is necessary to release (concurrently with OSversion 14) a new version of Bravo that contains the revised time software. Theconsequence of running an old Bravo under a new OS or a new Bravo under an old OSwill be that Bravo's "T" command will generate a time string that is wrong by 8hours. The new Bravo has been released.3. Implement the new-format time server on the Gateways and Maxcs. This step hasbeen completed.4. Release a new version of the SetTime subsystem that deals with either the old orthe new standard, depending on the version of the OS it is running under. The newSetTime has been released.5. Release the new version of the "Time" software package, described previously.This package will work correctly only under OS version 14. The new Time packagehas been released.6. Release new versions of all programs that deal with dates and times. Theseinclude Bravo, DDS, FTP, IFS, OfficeTalk, and undoubtedly one or more Mesasubsystems. The necessary modification consists of incorporating or transliteratingthe new version of the "Time" software package. Programs containing the newpackage will not work under OS versions prior to 14. The new Bravo has beenreleased. New versions of subsystems released after February 27, 1978 are notguaranteed to work under any OS prior to version 14.7. Update Mesa programs that deal with time. Mesa time-conversion softwareconforming to the new standard is available. Consult your local Mesa supportorganization.Several aspects of this transition should be noted. First, the compatible DayTime procedurein the OS will cease to work correctly when Daylight Savings Time goes into effect on April30, 1978. It is not practical for the OS to perform the calculation for correct handling of DSTbecause doing so requires most of the machinery of UNPACKDT. Therefore, we should striveto complete the transition before that time.Second, the date properties of all existing Alto files will become incorrect by either 7 or 8hours, depending on whether or not they were written when DST was in effect. I don't think frG b!q<)qrq/\Alto Time Standard5anyone will care (except on IFS, where I may undertake to convert all the dates). If anyonedoes care, writing a program to convert the dates on existing files should be straightforward.Maintainers of Alto subsystems are now requested to begin converting to the new standard. Itis desirable that this conversion be completed by March 31, 1978, so as to give users adequatetime to update their disks before compatibility with the old time standard ceases to work. frG bqr6 `1- ]u3* \/H Z@ Zc>/ = TIMESROMAN  TIMESROMAN TIMESROMAN LOGO TIMESROMAN  TIMESROMAN  TIMESROMAN  { }"$j/'%altotiME.BRAVOTaftFebruary 26, 1978 2:04 PM