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" UTC).
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 -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>