[LEAPSECS] presentations from AAS Future of Time sessions

[Magnus Danielson]

On 16/01/14 12:38, Tom Van Baak wrote:

>> The Multics clock design (a fixed bin (71), ie double word, representing microseconds

>> since 00:00 01-01-1900) clearly informs the Unix one.

>

> Was it 1900 or 1901? See:

> http://www.multicians.org/jhs-clock.html

> http://web.mit.edu/multics-history/source/Multics/ldd/bos/include/rdclock.incl.alm

> http://web.mit.edu/multics-history/source/Multics/doc/info_segments/datebin_.info

> http://web.mit.edu/multics-history/source/Multics/doc/info_segments/date_time_.info

> "If clock is not a valid date, "01/01/01 0000.0 gmt Tue" is returned."

>

> I spent years programming on GE-635 (GCOS/TSS). Multics used the GE-645 which had a special external microsecond clock:

> http://www.multicians.org/mgc.html#clock

>

> Yes, the Multics clock is very much like the one UNIX adopted. GCOS used a more traditional date and time format: 36-bits for date (mmddyy in BCD) and 36-bits for time-of-day (in 15.625 us = 1/64 millisecond units). GCOS had a weird convention of printing all times in hours with decimal places (no minutes or seconds). That was one of the things that I liked about UNIX; it used hh:mm:ss notation. The other thing to note is "Clock readings are Multics Greenwich mean time (GMT)". UNIX also adopted this. Most OS's back then, including GCOS, ran in local time.

>

> When I developed email in 1976 I encoded the BCD date (mmddyy) and BCD time (hhmmss) into two 18-bit binary fields. This worked because the maximum possible date was 123199, the maximum time was 235959, which just fit in the maximum half-word (2^18 = 262144).


OK, so Y2K problems where all your fault. BUSTED! :D

235960 would actually be possible to encode there, as well as all local 
time variants.

Cheers,
Magnus