the ``need'' for POSIX times
eggert at twinsun.com
Sun Oct 11 00:25:17 UTC 1998
Date: Sat, 10 Oct 1998 11:36:11 +0100
From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>
I don't like your terminology to call UTC-TAI values "real" UTC.
Fair enough. How about if we call the UTC-TAI based clock "internal
UTC", as opposed to "display UTC"?
what I consider to be the "real" UTC is the (displayed) UTC defined
in the IERS Bulletins C, and not some TAI display plus a UTC-TAI
offset as you seem to suggest.
But those bulletins define internal UTC as well as displayed UTC.
That is, they specify both UTC-TAI and the display format.
UTC-TAI is a first-class citizen in these standards.
the UTC-TAI difference (and not UTC itself) needs some extra definition
to be fully defined during an inserted leap
second. UTC-TAI over TAI diagrams will naturally have a one second
gap during inserted leap seconds (because the UTC clock goes into a
range where the TAI clock never was)
The time standard does not supply, nor does it need any ``extra definition''.
E.g. the latest IERS Bulletin C at
does not specify a gap in internal UTC. Governing bodies like the
BIPM publish diagrams graphing UTC-TAI over TAI that don't have any
gaps. And the IERS publishes tables that make it quite clear that
internal UTC is adjusted by subtracting inserted leap seconds from it.
For example, see:
Internal UTC is meant for clocks; display UTC is meant for humans.
That is, internal UTC is suited for implementations of clocks that are
based on counting seconds one-by-one; conversely, display UTC is
suited for displays meant for humans.
Adjusting clocks backwards is just a figure of speech to explain
DST switches to the general population without introducing proper
Sorry, you've lost me. Adjusting clocks backwards is a figure of
speech? In a couple of weeks, I'll be wandering over my house,
office, and car manually adjusting dozens of dumb localtime clocks
backward. On that day it certainly won't feel like a figure of
Nor is it a figure of speech with internal UTC; the ideal internal
UTC clock is adjusted when leap seconds occur.
> Then clearly the TIME_UTC struct xtime encodes
> "display UTC", not "real UTC".
You referred to "conceptual problems" around half a dozen times in
the last few messages without ever giving a concrete example of
what these are
We've discussed several such problems, including bogus leap seconds
(i.e. struct xtime values with nsec>=1000000000 that do not correspond
to actual leap seconds), and glitches with time arithmetic involving
true leap seconds.
I'm not saying that you aren't aware of these problems and aren't
working on solutions to them. What I'm saying is that they _are_
problems, and they require solutions, and that the solutions
complicate the model.
my equivalent of difftime is only three lines long, as I posted before.
But (as I mentioned earlier) that implementation has a double-rounding
bug. Also, the interface requires information loss if the times are
sufficiently far apart, at least on the vast majority of hosts where
double can't represent 96-bit integers exactly. There's no easy,
portable fix for either problem.
> struct xtime has many of the problems that these C
> implementations have (albeit in a more limited way)....
There is only the nsec overflow, and I wouldn't call the single if
statement necessary to handle it a "conceptual problem" (especially
since it is there for good reasons...
I think it's more than just a single if statement, and that people
will need if-statements sprinkled throughout their code.
Let me put the problem a different way. The time standard provides
two forms of UTC: display UTC and internal UTC, each with its own
advantages and disadvantages. struct xtime attempts to be a
compromise between the two forms, in order to have some of the
advantages of both.
Unfortunately, this means struct xtime also has some of the
_disadvantages_ of both. Some of these disadvantages are mentioned
Furthermore, struct xtime is not isomorphic to either display UTC or
internal UTC, so it has some problems that are uniquely its own
(e.g. values with nsec>=2000000000).
It would be helpful for the discussion if you published an actual
specification in a language close to something that could be copied into
Yes, and I'm working on it. Sorry, it isn't done yet; when it is, we
can do some comparisons (it'll be your turn to throw bricks :-). By
the way, I've found your discussions (along with comments by the
others) to be quite helpful in ironing out problems in the draft.
More information about the tz