Proposal for new ISO C 9x time API

[Markus Kuhn]

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