Paul Eggert wrote on 1998-10-02 11:43 UTC:
Related problem: 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, therefore the calculation you propose is not possible because how would you know whether to divide by 86400 or by 86401. The best semantic for this I can think of (and that is what I suggest to use in strfxtime for calculating the fractional minutes and hours!) is to replace nsec by max(nsec, 999_999_999) in algorithms that convert to a presentation without leap second encoding. The Julian Date just stops during the leap second. I think there is nothing else you can do. A more general remark about your earlier proposal against using a struct for xtime: In any arithmetic time type you simply can't insert leaps seconds properly. In order to insert leap seconds, you have to break down time into components and let the smaller component overflow. This is done in struct tm and on the UTC clock with the famous sec=60 overflow and it is also done in struct xtime with the nsec=1_000_000_000 overflow. The whole beauty of struct xtime compared to any proposal of using just an arithmetic time (essentially time_t again) is exactly that it is a time that is broken down at the second level such that leap seconds can be inserted by overflow of one component. In UTC, the minute flows over, in struct xtime, the second flows over. 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. You might call it state-less time, because there is no state such as a leap second table or a flag that a leap second is nearby involved in any of this. [BTW: An interesting, though more academic side note: since leap seconds can only appear at the end of minutes, it is a not too far fetched idea to break down time into a 32-bit minute counter since the epoch and a nanominute (nmin) counter which can overflow to 1 1/60 minutes in the case of a leap second. 32-bit minute counters cover a range of 9.8 kiloyears, which is quite reasonable as it covers most of the recorded human history. Equivalently, since leap seconds can only appear at the end of a UTC day, a MJD day and nanoday counter would be even better. A nanoday is 86.6 µs, which might already be a bit long for unique timestamps per server.] 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/>