the ``need'' for POSIX times

[Paul Eggert]

   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
http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
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:
http://hpiers.obspm.fr/webiers/general/earthor/utc/table2.html

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
   notation.

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
speech.  :-)

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
above.

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
   the standard.

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.