Date: Thu, 07 Feb 2002 18:05:43 +0000 From: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk>
The new definition relaxes that and allows for example an implementation to decide to implement the progression of the scalar system time near an inserted leap second by slowing down the system clock briefly.
Yes, and the POSIX 1003.1-2001 rationale is even more explicit than the official standard on this point. Here's a quote from <http://www.opengroup.org/onlinepubs/007904975/xrat/xbd_chap04.html#tag_01_04...>: It is a practical impossibility to mandate that a conforming implementation must have a fixed relationship to any particular official clock (consider isolated systems, or systems performing "reruns" by setting the clock to some arbitrary time). Note that as a practical consequence of this, the length of a second as measured by some external standard is not specified. This unspecified second is nominally equal to an International System (SI) second in duration. Applications must be matched to a system that provides the particular handling of external time in the way required by the application. Also, the POSIX editors went through the standard and replaced most instances of the phrase "seconds since 00:00:00 UTC (Coordinated Universal Time), January 1 1970" with "seconds since the Epoch". I think it's clear that the intent was that a POSIX system could use UTS <http://www.cl.cam.ac.uk/~mgk25/uts.txt> rather than UTC.
As I read it, the new definition still prevents implementations from making the system's scalar time an exact measure of physical time (e.g. by applying the provided encoding formula to a TAI clock display, instead of a UTC clock display) by the requirement of representing each day by an increment of 86400 "seconds" on the scalar clock.
I don't see why that requirement prohibits a system with a TAI time_t that has 86400 seconds per day. Suppose we make the usual assumption that the TAI time_t and UTC time_t values are identical on 1972-01-01, which means the two time_t values differ by 22 seconds now. Then, on a TAI-based system, "date -u" would output "Thu Feb 7 23:24:22 UTC 2002" at the same time that that a conventional UTC-based system would output "Thu Feb 7 23:24:00 UTC 2002". As I see it, that's consistent with the intent of the new standard. POSIX does require that gmtime use an 86400-second day, and that gmtime must return UTC, and I think this does prohibit a system that uses TAI time_t. However, this gmtime requirement seems to prohibit UTS time_t as well, and I don't think this was intended. POSIX 1003.1-2001 is a large new spec, with quite a few bugs (e.g. <time.h> allows tm_sec to be 60, which means it does allow leap seconds!), so it wouldn't be surprising if some interpretation requests were needed to shake out some of the problems here.