[LEAPSECS] presentations from AAS Future of Time sessions

[Ian Batten]

On 14 Jan 2014, at 23:53, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> 

> It's not like Ken & Dennis looked at leap-seconds and went "Naah,

> who cares", or even "braindead!  We'll skip that."


I think it would require slightly more software archaeology to determine who took what decisions about what.  The documentation for
the convert_date_to_binary_ routine on Multics addresses both Julian/Gregorian issues, which are allowed for  (although, as for the Unix cal(1) 
command, it assumes a single date for that transition) and also leap seconds, which are not.  The copy I've located is MR11.0 for 1985, but I'm
pretty certain that if I dug around in the loft and located my copy of the MR10.0 version it would be pretty much the same (I recall reading this
in the early 1980s).


> Multics accepts dates from the year 0001 through 9999. The Julian calendar is used 

> for dates from 0001-01-01 through 1582-10-04. The Gregorian calendar is used for 

> dates from 1582-10-15 through 9999-12-31. (The dates from October 5, 1582 through 

> October 14, 1582 do not exist. They were dropped when the Gregorian calendar was 

> adopted. The leap day is always February 29. The lower limit on dates of January 1, 

> 0001 AD was picked since it begins the era. The upper limit on dates of December 

> 31, 9999 was chosen to limit year numbers to four digits. The time zones as now 

> defined are used regardless of the year. The Multics date/ time system does not 

> account for "leap seconds" and, therefore, the difference between any two binary clock 

> values that are precisely an integral number of days (hours, minutes, seconds, etc.) 

> apart is guaranteed to be evenly divisible by the number of microseconds in a day 


The Multics design, if not the precise implementation of that entry point, definitely pre-dates the introduction of leap seconds.   The
Multics clock design (a fixed bin (71), ie double word, representing microseconds since 00:00 01-01-1900) clearly informs the Unix
one.  Early 16-bit Unixes went similarly for a double-word quantity, and accepted that microseconds were not viable without major
hardware support to deal with 64-bit arithmetic.   Unics (sic) pre-dates leap-seconds, and Unix had reached  second edition before
leap seconds became a reality.  As PHK says, at the time the precision of computer clocks, both in rate and phase, was such that
the need to adjust it by a second once every eighteen months was in the noise floor, and the design was by that time established.

So I suspect that at the time of adopting the Unix time_t (as it became), leap seconds were either not yet implemented or not
yet even proposed, and at the time of adopting the time framework for Unix's predecessor they definitely weren't.   That predecessor
system documented the lack of support for leap seconds as early as 1985 (proof above) and I think 1983.

ian