swh@hpcupt1.HP.COM (Steve Harrold) (01/24/90)
Does time() honor leap seconds? The value returned by time() is supposed to be the number of seconds since midnight Jan 1, 1970. Does anyone know if leap-seconds are supposed to be accounted for in this value, or is each year assumed to have the same length as any other year? The question is prompted by the fact that one second was inserted at the the end of 1989, _before_ 1990 began, by the international time-keeping organizations.
trt@rti.UUCP (Thomas Truscott) (01/24/90)
> 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