Does time() honor leap seconds?

[Thomas Truscott]

> The value returned by time() is supposed to be the number of seconds since
> midnight Jan 1, 1970.  [GMT]

Yes, and the elapsed number of seconds since the epoch is unaffected by
artifacts of man such as time zones, daylight savings time,
or leap seconds.
time() works like a stopwatch that was started at the epoch.
Do stopwatches honor leap seconds?
I would say that they neither honor nor dishonor them.

The complications of leap seconds arise with ctime()
and other routines that manipulate human-readable versions of the date.
The UNIX V7 ctime() handled time zones and daylight savings time
and leap days but had nothing in it for leap seconds.
That means it produces incorrect results (currently it is off
by about a dozen seconds).  It isn't noticed because
the inverse of ctime() -- ugly code wired into the date command --
is similarly incorrect.  In effect, the bugs in ctime() et al.
have moved the epoch about a dozen seconds past midnight.

So what should we do?  We should officially make
the epoch "00:00:12 Jan 1 1970 GMT"
(alternatively we could declare current versions of ctime() invalid).
And then require and provide versions of ctime() et al.
which can handle future leap seconds properly.

It is regrettable that the ctime() leap seconds bug has festered,
but it is not too late to fix it.
Some standards committees have tried to canonize this bug by
specifying that ctime() should "ignore leap seconds".
It is hard to find a charitable interpretation for that!
	Tom Truscott