comments on draft ISO C9x changes to <time.h>

[Antoine Leca]

Joseph S. Myers wrote:
> 

First, thanks for your input.

> On Mon, 15 Jun 1998, Antoine Leca wrote:
> 
> > OTOH, in the realm of POSIX, there is a quite natural
> > extension to this mechanism which fits the need:
<snip: a mechanism>
> 
> It might make sense to use the same sort of interface as for the POSIX.2
> regular expression functions, e.g.
<snip: another mechanism>

I am not competent enough to discuss this point.
However, I shall transmit this to the "liaison", i.e. to the person
in charge of keeping the POSIX standard in line with the C standard
(which happens to be Keld Simonsen).

Anyway, it appears to me that there is no real problem to have
*in the POSIX realm* mechanisms that permit fine selection
of the time zone, viewed as a part of the world.

Do I rewrite correctly your point?


> > For the leapseconds, there is first a very delicate inter-
> > operability problem, since POSIX.1 request time_t value to
> > *not* record any leap second information at all.
> > So I have no practical solution here, outside the one
> > proposed in CD1, i.e. to extend struct tm to have a new
> > field storing this information.
> 
> The most compatible solution would be to use Markus Kuhn's CLOCK_UTC with
> nanosecond values up to 1999999999 during leap seconds (and if the system
> clock ticks TAI the library handles the conversion using a leap second
> table).  This would however require new interfaces for time conversion
> that take times with nanoseconds.

This seems feasable; I have just a question: when there is a
"step" leap second, i.e. when Terra is turning faster (clocks
are going from 23:59:58 to 00:00:00), how is it supposed to be
handled in this mechanism?

However, I see this as requiring a new field, here to hold the
nanoseconds, so in effect it returns to CD1 solution (a new
structure), since the C Comittee is reluctant at inserting new
"full-class" fields in struct tm because it breaks binary
compatibility.

 
> What is the `correct' time display to give for a leapsecond in a zone with
> an offset from UTC that is not an integral number of minutes?  Have there
> actually been any such zones since the start of the leapsecond system?

I do not know of, except of course Saudi Arabia (but their system
is entirely different, and is not covered here).  I think that
introducing leap seconds require some level of technology available
that is not compatible with keeping clocks at local mean time
instead of using the world time zones system; but I may be wrong.


Antoine