On 14 Jan 2014, at 23:53, Poul-Henning Kamp <p...@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 _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
