Date: Sat, 10 Oct 1998 11:36:11 +0100 From: Markus Kuhn <Markus.Kuhn@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.