Paul Eggert wrote on 1998-10-02 19:10 UTC:
Why not? The day is just 1 second longer, so you use a denominator of 86401 instead of 86400 when computing the fraction. Of course you should use the larger denominator throughout the day, not just during the leap second.
No, this doesn't work: All timestamps during the preceding day do not contain a marker that they are part of a 86401 seconds long day,
They don't have to contain a marker. You can figure it out by looking at what day the timestamp is in, and then consulting the leap second table (and time zone table, of course).
Apparently one if your goals is that strftime should not have to consult a leap second table, even on systems that support leap seconds. I don't see why this is a desirable goal.
One of the fundamental concepts behind my API is exactly to make sure that there are only two functions, which would access to a leap second table, and both are optional, that is are always allowed to return that they have no information available. These two functions are xtime_conv() and tz_jump(). They allow you to access and iterate trough a leap second table. All other functions are *never* expected to access a leap second table (and this includes xtime_add and xtime_diff, to be added soon). If you think that any of the other functions need access to a leap second table, then you probably haven't yet understood the fundamental design principle behind my API. Why? In my opinion, leap second tables are a very dubious and extremely dangerous concept. In real life, they are practically guaranteed to be out-of-date on most systems and if we build leap-second tables into the architecture of the API as a fundamental and not as an auxiliary element, then I see already a long list of comp.risks postings coming in the next decades which report about bad things that had happened in distributed systems due to inconsistent and out-of-date leap-second tables, and what fools the designer of the C time API have been to introduce such an irresponsible concept. Therefore I want to have the leap second table access strictly restricted to the two auxiliary functions xtime_conv and tz_jump.
In any arithmetic time type you simply can't insert leaps seconds properly.
Obviously you need a boolean as well as the arithmetic time value, to denote the fact that the time stamp is within a leap second. The question is: how do you encode the boolean? The struct xtime proposal encodes the boolean as part of an out-of-range sub-second value. But I think it's more straightforward to encode it as a boolean.
I *have* played with this idea and written example pseudo-code for both nsec overflow and boolean leap second indicators. I found the nsec overflow to be slightly simpler to implement and slighly more intuitive. In addition, it does not waste any bits if only non-UTC clocks are used. I agree that it is possible to define an alternative struxt xtime that consists of just an arithmetic time scale without an encoding for inserted leap seconds, plus a separate boolean flag (at least 8 bits that mess up word alignment!) that indicates a leap second and uses the encoding values of the preceeding or following non-leap second to represent the leap second. Another idea I have played around with is to use the LSB in the arithmetic type. I was not too happy with any of the results of these gedankenexperiments. The nsec overflow idea is not just a quick first idea: I have considered many alternatives and in order to convince me that my considerations where wrong you will certainly have to present me with a good discussion of the detailed implementation advantages of your encoding versus mine, because I do see many disadvantages of your system compared to mine.
Having a time type that allows to represent leap seconds by internal overflow and having separate UTC, monotonic, and perhaps also TAI clocks is the very crux of getting rid of the necessity of leap second tables.
I don't understand this point. First, you cannot get rid of leap second tables if you want to convert properly between UTC and the other formats, on systems that support leap seconds.
As I said before, I want to restrict the access to the dangerous leap second tables to two functions. If programming guide lines in a project forbid any semantic dependency on leap seconds, then to verify this guideline, in my API you only have to study calls to xtime_conv() and tz_jump() in order to understand potential effects of out-of-date leap-seconds tables. In the other proposals for handling leap seconds that I have seen, almost everything depends on correct leap second tables (especially in the "let's only use TAI" proposals), and it is almost impossible to avoid semantic dependence on them. This can have serious saftey and security implications IMHO.
Second, if you represent a UTC timestamp with an integer plus a boolean leap-second flag, you have exactly the same information that you would have with struct xtime (assuming XTIMES_PER_SEC is 1000000000). So I don't see why one system is any better than the other in terms of avoiding leap second tables.
It is certainly identical in terms of separating the dependency of leap-second tables. Main advantages of my representation are: I utilize the memory layout of the struct better, I enable compatibility with POSIX struct timespec, and I think the example code I have played around with looks neater.
I agree that the C standard should allow sloppy implementations that don't know about leap seconds; those implementations won't need leap second tables at all, of course.
Systems with and without leap second tables should only differ in their semantic in a small and well-defined way, and I think my proposal provides exactly this. 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/>