First proposal for new ISO C 9x time API

[Markus Kuhn]

"Joseph S. Myers" wrote on 1998-09-04 20:38 UTC:
> It would be a good idea to use a common prefix for the structure elements
> (xtm_nsec, xtm_sec, etc.).

I never understood what these common prefixes are good for.

What is the reason for calling struct elements tm_sec, tm_min, etc.
instead of sec, min, etc.? I find them rather strange and ugly.

> >   int   offset; // minutes east off UTC
> 
> Seconds might be better.

I think it was a error to allow seconds in the TZ offset in POSIX.1, and
I would like to avoid copying such intellectual accidents of the POSIX
authors into this proposal. If a local time zone really were defined to
have a fixed offset relative to UTC that is not an integral multiple of
minutes, then bizarre things would happen near UTC leap seconds.

If some politician really should decide that his local time is say 5h 7m
42s behind UTC, then we can't handle this appropriately anyway, and then
specifying -04:08 is as acceptable in this silly situation as would be
anything else. You would never use such an esoteric time zone for
precision applications anyway! Historic time zones with a non-minute
offset relative to GMT (UT0, UT1, UT2, etc.) are not defined relative to
UTC, and therefore we shouldn't IMHO create the false impression that we
could support these with second precision.

I prefer sound and consistent semantics here, and I think they are only
possible with minute UTC offsets.

If you think that civil time zones defined relative to UT1 will become
fashionable one day, then why on the other side should we allow only second
resolution and not add nanoseconds in addition?

I feel the KISS principle dictates minute offsets here.

> What is appropriate in canonicalisation if the seconds value is 60?  The
> natural expectation is that this causes the minutes to increase unless we
> are at a leapsecond - but this requires a leapseconds table.  The
> alternative, ending up with nanoseconds of 10^9 in the struct xtime, seems
> unfortunate.

I have been thinking about this, and the only reasonable solution I can
think of is that we always assume that we do not fall into a leap
second. After all, this is only wrong with a probability of less than 1
in 40 million. I cannot think of an application where this would matter.
Note that MANY of the previously necessary applications of mktime vanish
by the simple fact that we now introduce a well-defined encoding for
TIMEOPT_UTC. You do not have to abuse mktime any more to add an hour in
a portable way to a time_t. If you care mainly about time intervals and
not about UTC, then you should use TIMEOPT_MONOTONIC, which gives you a
leapsecond free time scale (which on implementations with a battery
clock like every PC has one can even survive across powerdowns). An
equivalent of difftime is not necessary in this API for the very same
reason. Just don't abuse UTC to calculate time intervals.

Thanks a lot, also for your very good other comments. I'll try to consider
them in the next draft.

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