[LEAPSECS] presentations from AAS Future of Time sessions

[Poul-Henning Kamp]

In message <52D20BEB.60709 at edlmax.com>, Brooks Harris writes:



>Yes, in my opinion its unfortunate they chose to use the term "UTC" in

>that context.


They chose UTC because they meant UTC.

I have this directly from multiple persons who were involved back
then, including Dennis Ritchie who gave me the full sordid details
about the early UNIX' requirement of weekly recompiles to update
the epoch of the timekeeping.

The reason why they didn't cater to leap-seconds ?

They hadn't heard about them at the time.

And even if they had, they likely wouldn't have bothered, since the
PDP-11's kept time based on the mains grid frequency and Ken Thompsons
wrist-watch.

The trouble starts when Bell Labs starts to commercialize UNIX,
polishes the manual pages and goldplates them as "System V Interface
Definition" in 1985, without checking if there are any implicit
references to Ken's watch that needed to be resolved.

Interestingly, leapseconds appear in network time protocols for the
first time in 1985, where previous prototypes does not have support
for them, despite the leapseconds in '81, '82 and '83.

Later the manual pages also became X/Open, which were fostered by
a group of UNIX vendors who wanted BSD networking rather than
STREAMS, because the former worked while the latter really didn't,
and they didn't notice the bit about leap-seconds either.

Eventually it all became dumbed down to POSIX so that Windows NT,
VMS and MVS could also qualify, which is were all the crappy APIs
(timespec, clock_t etc.) comes from as far as I remember.

...and then the dot-com boom happened, multiplying the cadre of programmers
by a factor 1000 and reducing the average knowledge and skill level by
the same factor, at the same time as leap-seconds took a break.

The rest is (also) history.

But time_t has always been UTC, because it was meant to be UTC.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.