Date: Fri, 02 Oct 1998 18:08:13 +0100 From: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk>
What is the semantics of decimal fractions of minutes and hours during a leap second. These are obviously illdefined and a neat solution is not possible
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. 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. 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. 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. 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.