the ``need'' for POSIX times

Markus Kuhn Markus.Kuhn at
Sat Oct 10 10:36:11 UTC 1998

Paul Eggert wrote on 1998-10-10 00:24 UTC:
> By "real UTC" I mean the sort of UTC described by Fig. 2 of Terry
> Quinn, The BIPM and the Accurate Measure of Time, Proc IEEE 79, 7
> (1991-07), 894-905.  This is the UTC that is denoted in the expression
> `UTC-TAI', which is commonly used to denote how many leap seconds have
> been inserted.

Well, 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. Obviously, 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), and it is a matter of
convention of how you fill this gap if you depend on a continuous
fail-safe representation of UTC-TAI. Observe what xtime_diff is doing in
this case: It will fill this gap in the UTC-TAI graph smoothly by linear
interpolation between 23:59:60 and 00:00:00, which is IMHO the most
useful semantics in this case. (In the case of deleted leap seconds, you
never have any such ambiguity anyway.)

> This
> graph makes sense only if UTC clocks are adjusted backwards by one
> second during a leap, as I described above.  That is, the `:60'
> notation is used to disambiguate leap-second timestamps, but it's not
> part of "real UTC".

No, the ":60" is the real UTC. There is a full inserted second (an
interval of time with its own unique name) that never appears on a TAI
clock. The idea of "adjusting UTC backwards" is something that you have
made up. I haven't found this notion anywhere in the literature, and I
also consider it not to be very helpful. Adjusting clocks backwards is
just a figure of speech to explain DST switches to the general
population without introducing proper notation. UTC is much better and
stricter defined than most local times. You have set up yourself a
fairly complicated model of thinking about UTC. Just stay strictly with
the UTC as defined by the letter of ITU-R TF.460-4 and the IERS
Bulletins C, and you stay out of such conceptual troubles.

>    Struct xtime is just a simple fully static encoding of the full
>    YYYY-MM-DD HH:MM:SS display as found on any official UTC clock.
> Let's call this display "display UTC", as opposed to the "real UTC"
> mentioned above.  Then clearly the TIME_UTC struct xtime encodes
> "display UTC", not "real UTC".

OK (although I don't like your terminology to call UTC-TAI values "real"

> Another way to say it is that struct xtime is a broken-down
> representation of UTC, one that contains a special encoding to
> disambiguate UTC timestamps within leap seconds.  struct xtime is not
> as broken-down as struct tm is, but it _is_ broken-down to some
> extent.

Correct. It is broken down once, in order to allow a :60 overflow just
as on a displayed UTC and to provide the necessary range and resolution.

> And its conceptual problems stem from this fact.

Which are? 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 and why your modified TAI does not have them but why the
combination of TIME_MONOTONIC and TIME_UTC in the context of my API does
have them. I still don't understand exactly, where you see these
problems. A real live application example that is elegant in your API
but very clumsy in my API would be helpful here.

> I've heard that, in some C implementations, time_t encodes a
> broken-down value, so that localtime simply picks the bits out of the
> encoded representation and stuffs them into the struct tm.

I've never seen any of these, but it probably is possible to do a
correct implementation this way. Say time_t is a 64 bit word (16
nibbles) with a YYYYMMDDHHMMSS.SS BCD encoding (10000 years range, 10 ms
resolution, leap seconds possible, certainly better than many other
encodings that I have seen).

> This
> conforms to C89, but it means time_t is quite inconvenient to deal
> with directly.

Agreed, it is inconvenient in that not only difftime will have to
transform everything first to a sec scale, but also that in that
localtime will have to add the UTC offset and then adjust the
broken-down representation for minute, hour, day, month, and year
overflows. struct xtime has none of these problems, because it has no
minute, hour, day, month, and year overflows. And my equivalent of
difftime is only three lines long, as I posted before.

> struct xtime has many of the problems that these C
> implementations have (albeit in a more limited way).  I'd prefer an
> internal representation that didn't have these problems, if one is
> possible.

Which problems? It would be much easier for me to answer if you'd
actually name them. It obviously can't be the minute, hour, day, month,
and year overflows, because struct xtime has none of these. 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: to allow leap seconds to be encoded, do provide
a comfortable range and resolution, and to allow for compatibility with
POSIX's struct timespec).

>    There exists no eternally valid static algorithm for this
>    conversion in your modified TAI, because the timestamp versus
>    displayed time relationship changes each time you update a leap
>    second table.
> True, but any application requiring such an algorithm should not use
> TIME_TAI; it should use TIME_UTC.

OK, so my critique here was then based on the unfortunate fact that you
have not yet published a full proposal and I have not yet had a chance
of completely understanding what precisely is the set of clock and
timestamp types that you plan to offer. My example was based on the
assumption that you are in the TAI-only fanatics camp with Mr. Libtai.

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. Based on what you said so far, I am confident that I can
efficiently implement your additional clocks with very few lines of code
on top of xtime_get(..., TIME_UTC) and tz_jump() (note that both
functions give you full access to "displayed UTC" plus a window of
nearly leap seconds, even if CLOCK_TAI is not available, as you required,
which is exactly what you get from NTP and DCF77). But to proof this, I
obviously have to see your precise specification first.


Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at,  home page: <>

More information about the tz mailing list