Proposal for new ISO C 9x time API

[Markus Kuhn]

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/>