UTC questionnaire

[Markus Kuhn]

"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/>