Date: Fri, 09 Oct 1998 23:13:35 +0100 From: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> Paul Eggert wrote on 1998-10-09 19:16 UTC:
struct xtime's TIME_UTC is not really UTC, as TIME_UTC clocks have special values during an inserted leap second, whereas UTC clocks simply go back 1 second.
... There is absolutely no conceptual difference between "real UTC" and TIME_UTC, since there exists an obvious bijective deterministic mapping between both. No, because "real UTC" is ambiguous during inserted leap seconds. 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. Since 1972, the graph of UTC-TAI versus time has been a staircase function that looks like this: --+ +----+ +---------+ +---.... where each decrease corresponds to an inserted leap second. 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". 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". 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. And its conceptual problems stem from this fact. 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. This conforms to C89, but it means time_t is quite inconvenient to deal with directly. 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. 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. You enter into this electronic commerce system a command to rejects all contracts that expire after 2000-01-01 00:00:00, Such an application should not use TIME_TAI for future timestamps, obviously. But, for the purpose of this discussion, let's assume that the programmer made a bad mistake and wrote code that attempts to convert every timestamp to TIME_TAI internally, even future timestamps. It converts the 2000-01-01 00:00:00 cut-off date into an integer timestamp T based on the assumption that there will not be a further leap second until then as the current table suggests. No, the implementation will report an error when the application attempts to make the conversion, since leap seconds aren't known that far in advance. That will preclude the later problems mentioned in your scenario. This issue is independent of whether the API uses struct xtime or an integer clock. there are numerous applications, where we care much less about the real number of seconds until some date than we care about what exactly the precise official UTC notation for this date Yes, and such apps should use TIME_UTC. My TIME_UTC (and also POSIX) provides this reliable relationship between the easy to process integer struct value and the full broken-down time. My proposal won't change this. (POSIX.1 is a special case of my proposal.) Your modified TAI does not provide this reliable relationship! Nor does the unmodified TIME_TAI. (Sorry, I don't see why these points are relevant.) Just think about legal investigations in the context of some fraud, where timestamps in digitally signed documents were encoded using your modified TAI encoding. I wouldn't recommend that people use such timestamps for that purpose, any more than I would recommend that they use TIME_MONOTONIC. The modified TIME_TAI clocks have an implementation-defined epoch, among other things. The code wouldn't even get off the ground; it'd be a silly thing to try. I consider [the struct xtime proposal] to be ready for standardization. I can't agree. It's not implemented yet. We don't have any real-world experience with it. Even assuming we're willing to live with its conceptual problems, a lot of work is needed before it's ready for standardization. And I'd prefer a spec that had fewer conceptual problems, before implementation begins.