Doug Gwyn <gwyn@arl.mil> writes:

...

UNIX "system time" is *unaffected* by Daylight Saving Time; it always counts clock ticks since a fixed epoch, which progresses unformly regardless of legislative actions. The mapping to/from human-being time is performed by library functions that can be instructed as to the exact rules to be applied

Do you believe this concept should be extended to leap seconds?

I'd certainly vote that way.

The `ado' time package proves such an extension is feasible. (The only slight problem I've seen in practice is with programs that assume every minute has 60 seconds.)

ANSI C made an effort to allow minutes with more than 60 seconds (Doug may even have been the one who pushed them to do that), although, as you note:

However, POSIX seems to legislate the possibility away,

As I remember, the POSIX people seemed just to be confused; I never heard anything from them indicating that they actually understood the issue. The POSIX spec says Most systems' notion of "time" is that of a continuously-increasing value, so this value should increase even during leap seconds. So, far, so good - that's 100% correct - but they then go on to say: However, not only do most systems not keep track of leap seconds... which is true only because, at the time POSIX was published, most UNIX systems didn't have the Olson code. I.e., there was no rocket science involved with *making* UNIX systems handle leap seconds - the system supplier just had to pick up the code you wrote and the tables. Unfortunately, POSIX's erroneous decision gave a strong incentive *not* to do so.... They continue: ...but most systems are probably not synchronized to any standard time reference. Therefore, it is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the reference time and the Epoch. which is certainly correct, but, as I remember, I presented precisely that argument in an attempt to get POSIX to *ALLOW* leap-seconds to be used - i.e., given that most systems aren't synchronized, worrying about a few leap seconds in those systems is silly and shouldn't be used to justify forbidding a system to keep track of them, and, on those systems that *are* synchronized, you probably *want* to keep track of leap seconds! They then proceed with: It is important that the interpretation of time names and "seconds since the Epoch" values be consistent across conforming systems. That is, it is important that all conforming systems interpret "536 457 599 seconds since the Epoch" as 59 seconds, 59 minutes, 23 hours 31 December 1986, regardless of the system's idea of the current time. The expression is given to assure a consistent interpretation, not to attempt to specify the calendar. The relationship between "tm_yday" and the day of week, day of month, and month is presumed to be specified elsewhere, and not given in this standard. Consistent interpretation of "seconds since the Epoch" can be critical to certain types of distributed applications that rely on such timestamps to synchronize events. The accrual of leap seconds in a time standard is not predictable. The number of leap seconds since the Epoch will likely increase. Such distributed applications, I suspect, don't give a damn whether "536 457 599 seconds since the Epoch" is 31 December 1986 23:59:59 or not; I suspect they largely deal only in "units of time since some standard epoch" values, not in those peculiar labels that humans insist on using to designate instants of time. If any *do* care, I suspect they could be fixed not to care. I.e., the only places I'd expect the behavior of "localtime()" and "mktime()" and "gmtime()" and company with respect to leap seconds to be relevant are: 1) when interacting with human beings, i.e. printing out times or writing them in human-readable form to a file, or reading them from what some person types in - but I suspect the only effect on humans would be very occasional confusion if the human happens to say "date" and it calls "time()" when the leap second is in progress and prints out a date value like "12:30:61". 2) when interacting with some time source that deals in human-style time labels rather than time units since some epoch - but either 1) that time source knows about leap seconds, in which case it might be a *good* thing for "localtime", "gmtime()", "mktime()", and company to take leap seconds into account; 2) that time source *doesn't* know about leap seconds, in which case it's probably off by a few seconds, and the fact that "localtime()" or "mktime()" or "gmtime()" produce labels that are off by a few seconds probably doesn't matter anyway.

and the NTP implementors seem to favour a complex system that jumps the clock.

I may be misreading the spec, but, given that the NTP V3 timestamps are, in fact, represented as time units since some epoch (2^-32-seconds since 00:00:00 UTC January 1 1900, as I read the spec), I think the whole point of leap seconds in NTP V3 is to inform NTP clients that, when converting time-units-since-some-epoch time stamps to human-style labels, the scale used to do such conversion will shift. In particular, they correctly note that The insertion of leap seconds in UTC and subsequently into NTP does not affect the UTC or NTP oscillator, only the conversion to conventional civil UTC time. The UNIX clock is assumed to track the UTC or NTP oscillator, i.e. to start at 0 at some particular UTC value, and go up by 1 every time the oscillator goes up by some value of N. "gmtime()" is the routine that converts the UNIX clock to "conventional civil UTC time", as I understand it. I.e., I suspect that they're trying to cope with systems that don't know how to take leap seconds into account when converting timestamp-style clocks to "conventional civil time"; however, as UNIX systems with the Olson code including your leap-second code, and with timezone files containing correct leap-second data, *do* know how to take leap seconds into account while doing so (even if they risk the wrath of the Institute of Electrical and Electronic Engineers in doing so).