Proposal for new ISO C 9x time API

[Paul Eggert]

   Date: Fri, 02 Oct 1998 18:08:13 +0100
   From: Markus Kuhn <Markus.Kuhn at 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.