# the ``need'' for POSIX times

Paul Eggert eggert at twinsun.com
Fri Oct 9 19:16:32 UTC 1998

```   Date: Fri, 09 Oct 1998 13:00:37 +0100
From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>

we first have to "conceptually" shrink the borders of the leap
second to a zero interval, and then the original leap second
timestamp gets trapped at 24:00:00 from where you continue with
normal arithmetic.

An alternative (probably much more intuitive) model of thought for the
same behaviour is the following: TIME_UTC does not count leap seconds as
real time. It ignores the time inserted by a leap second. Think of it in
the following Image: If you drive with your car along the timeline,
think of leap seconds as slippery intervals of the street of time where
they ignore the leap second.

These models are entertaining, and it's fun to play with the algebra,
but I fear that you've been involved with the problem a bit too much,
and you need to step back and take a deep breath.  We need a model
that's simple and easy to explain; the explanations above are neither.

So.... why not use the official model instead?  Officially, since
1972, UTC-TAI has been a (negative) integer number of seconds, and
when a leap second is inserted, UTC-TAI decreases by 1.  What this
means is pretty simple: on an implementation whose internal clock
ticks TAI, the UTC clock ticks right along with the internal clock --
except during an inserted leap second, where the UTC clock is adjusted
back by one second.

When converting a UTC clock to a printed representation, it's
conventional to use :60 for the inserted leap second, but this is
merely a notation to indicate that the UTC clock is repeating, much as
the German-standard 'A' and 'B' suffixes are notations for repeated
local time when the UTC offset decreases.

Viewed in this light, struct xtime's TIME_UTC is not really UTC, as
TIME_UTC clocks have special values during an inserted leap second,
whereas UTC clocks simply go back 1 second.  TIME_UTC is therefore a
compromise between UTC clocks (which are not monotonic) and POSIX
clocks (which have no leap seconds).  TIME_UTC therefore suffers the
complexity of a solution that is neither fish nor fowl.

The struct xtime proposal would be simplified if it didn't use this
complicated interface, and instead used either true UTC, or true
POSIX.  (Of course, both true UTC and true POSIX could be supported,
by having two different clock types.)  I am dubious about
standardizing on a new halfway-between-UTC-and-POSIX clock type that
has never been used in practice and which has some nontrivial
conceptual problems.

```