Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!ulysses!allegra!alice!dmr
From: dmr@alice.UUCP
Newsgroups: comp.bugs.4bsd
Subject: Leap seconds
Message-ID: <7622@alice.UUCP>
Date: 14 Jan 88 09:18:00 GMT
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 43
Posted: Thu Jan 14 04:18:00 1988

It seems to me that the POSIX wording ("ignoring leap seconds")
is essentially correct, though the specs could be made more precise.

One postulate (not related to time as such) is that it would be rather
impolite to make everyone change their ctime function to get reasonable
conformance.

A second postulate is that the successive numbers returned by time(2) should
increase by 1 each second, and not skip or pause.

A third is that time errors in the distant past are considerably less
important than ones near the present.

Ctime operates by dividing the value of time(2) by 86400 to get days,
converting this to YY/MM/DD, and converting the remainder to HH:MM:SS.

Because of leap seconds, there are not always 86400 sec/day; thus ctime ignores
leap seconds (as specified by POSIX).  But the time "now" is correct.

So where did the leap seconds go?  One way to think of the situation is
that the epoch (and in fact all times before the leap second) moves
whenever we have a leap second.  Practically always, all this means is
that doing ctime() on a old date will be wrong by some number of
seconds.  Most people don't care; those who do, can install a nicer
ctime like the posted one.

It is true that if you execute "while sleep(1); do date; done" across
a leap second, you will not ever see the time "23:59:60" as you should;
and moreover, your ctime will be off by 1 sec until you do something
(reboot, jam the clock, skew your clock by listening to WWV, whatever).
I claim that for the vast majority of people, this witching period
(where an "old date" is in fact recent) is of little consequence; if
it is, they can fix their ctime to know about the leap second.

What would be wrong is to change the meaning of time(2) as
interpreted now, for any value of now.  For example, we run a WWVB
synchronized time server that puts out Unix Standard Time on a
network, and probably some hundreds of machines use it directly or
indirectly.  We would consider it unfriendly to jump the number it puts
out, and force everyone to change their simplistic ctime routines that
work well almost always.

	Dennis Ritchie