"D. J. Bernstein" wrote on 1999-12-04 01:12 UTC:
2. To correct some information you've received about UNIX: UNIX does not keep track of time in UTC. UNIX keeps track of time as an integer (plus, in some cases, a 6-digit or 9-digit fractional part) that counts seconds.
Which - as you said later - is not what the POSIX standard says and it is also not what the NTP developers (or I) consider to be desireable, especially considering the current unpredictability of UTC-TAI and the current unavailability of TAI from most time broadcasting stations (GPS and Omega being the notable exceptions). Even though many Unix man pages describe the value returned by time() inaccurately as "time since 00:00:00 GMT, January 1, 1970, measured in seconds" the value is actually defined in POSIX.1 to be just a fixed encoding of UTC, and *not* a second count. This is also what NTP implementations do and what de-facto most Unix applications expect. It would become a second count only if UTC stopped to have leap seconds.
The bulk of UNIX time-handling software simply adds or subtracts these integers to schedule or measure real-time events.
The bulk of UNIX software also uses a fixed formula to break the time_t value down to a decomposed yyyy-mm-dd hh:mm:ss time. The standardized mapping of time_t to UTC in POSIX was essential, because numerous protocols (NFS, all the CORBA stuff, etc.) exchange time_t values or equivalent encodings across networks.
The popular Olson tz library in ``right'' mode interprets the counter as the number of TAI seconds since 1970-01-01 00:00:10 TAI, and converts it to local time for human display, taking account of leap seconds. It can also convert from local time back to the counter. Many applications call this library.
But almost nobody uses this "right mode", because it violates not only the POSIX definition of time_t, but also breaks numerous existing applications (causing a TAI-UTC error to show up in many distributed timestamps), right?
UNIX predates leap seconds!---and this mistake was codified in the POSIX standard, along with an incorrect leap-year rule.
Unix (like most all other OSes, except for a few special embedded real-time environments for avionics applications) started off with a somewhat naive clock model, and didn't provide for a distinction between a TAI and UTC clock. Once the distinction was established, the Unix community decided to go with the UTC clock and not with TAI, because the compatibility with time announcement services was deemed to be much more important than the occasional missing second in interval measurements. In many applications (especially service charging, financial transactions), it has now become a well-established tradition to not charge for leap seconds. This works remarkably fine in practice and allows you to use the naive subtraction on the encoded UTC timestamps to get the desired and (often even by contract!) agreed semantics. At least the power and telecoms industry is very happy to tolerate the 0.000002 % financial loss/gain made this way, as this is way below the rounding noise in their other accounting procedures. There are important process control, physical measurement and navigation applications, where sub-second interval time measurement is no doubt required. Traditional Unix, mainly due to its absence of a static-priority real-time scheduler, was never considered to be an environment suitable for these fields. Special POSIX real-time operating systems usually do have separate so-called "monotonic" time-scales. This is the reason, why the POSIX.1 clock_*() functions have a clock type parameter, because although only a naive clock type CLOCK_REALTIME is defined by POSIX.1:1996, the parameter is there to allow programmers to switch between the naive Unix wall-clock/UTC clock and other clocks with different trade-offs for interval measurements. There was a POSIX real-time group proposal to add a CLOCK_MONOTONIC clock type to the clock_*() functions a couple of years ago, but I don't know, what the current status of this it. It seems, that most of the POSIX group has broken up before these projects could be finished. In any case, I have taken up the ideas from this old POSIX proposal in http://www.cl.cam.ac.uk/~mgk25/c-time/ which is a proposal to add clock types with different trade-offs for real-time applications to the ISO C API. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>