UTC questionnaire

Paul Eggert eggert at twinsun.com
Sat Dec 4 23:57:51 UTC 1999


   Date: 4 Dec 1999 01:12:56 -0000
   From: "D. J. Bernstein" <djb at cr.yp.to>

   UNIX does not keep track of time in UTC.

But POSIX specifies UTC, and the ideal internal POSIX clock matches
the UTC clock.  If the definition of UTC were changed, then POSIX's
definition of time would change accordingly.

It's common for confusion to arise in this area, because a common way
to look at UTC is as a broken-down representation like 1998-12-31 23:59:60.
These broken-down representations have always increased monotonically.

But the official definition of UTC is based on TAI, and it is this
definition that POSIX specifies for its internal clock.  Since 1972
this clock has been adjusted backward by 1 second immediately after an
inserted leap second, and therefore has counted TAI seconds except
that it ignores completed leap seconds.

The UTC clock is not monotonically increasing: it is ambiguous during
an inserted leap second and the second thereafter.  The common
broken-down representation of UTC resolves this ambiguity by using
``:60'' to denote an inserted leap second, but the ambiguity is
present in the UTC clock itself.

The discrepancy between POSIX time and UTC time arises only in
broken-down representations.  POSIX makes no provision for leap
seconds in broken-down representations, so clock ticks look like this
near an inserted leap second:

TAI-UTC TAI broken-down         UTC broken-down         POSIX broken-down
31      1999-01-01 00:00:30     1998-12-31 23:59:59     1998-12-31 23:59:59
31      1999-01-01 00:00:31     1998-12-31 23:59:60     1999-01-01 00:00:00
32      1999-01-01 00:00:32     1999-01-01 00:00:00     1999-01-01 00:00:00
32      1999-01-01 00:00:33     1999-01-01 00:00:01     1999-01-01 00:00:01

In practice, few (perhaps zero) POSIX hosts follow the POSIX
definition exactly.  Most fudge the issue by ignoring leap seconds,
relying on manual intervention to adjust the clock eventually.  Some
hosts artificially lengthen seconds near an inserted leap second and
skip the leap second, so that the internal clock continues to increase
monotonically.  A small number of not-quite-POSIX hosts use a TAI
internal clock along with a UTC broken-down representation.  All these
solutions have drawbacks.

If the definition of UTC were changed to use leap minutes rather than
leap seconds, POSIX itself would not need to change.  A table much
like the above would apply, except that TAI-UTC would increase by 60,
not by 1, and the POSIX broken-down representation would repeat a
minute, not just a second.  All the methods currently used to fudge
leap seconds would apply to leap minutes too.

However, I'm puzzled as to why the change is being proposed.  Hosts
are becoming better-connected, and this alleviates the hassle of
updating leap-second tables, which as I understand it is the principal
objection to leap seconds.  If we go to a leap-minute regime we'll be
facing a Y2k-like problem every century or so.  Isn't it better to
stick to the current regime of adjusting every year, so that the
relevant software is tested more often?



More information about the tz mailing list