Proposal for new ISO C 9x time API

[Antoine Leca]

Ken Pizzini wrote on tz at elsie.nci.nih.gov:
> 
> In message <199809182051.NAA01889 at shell7.ba.best.com>,
> Nathan Myers <ncm at best.com> writes:
> > Can we discuss the rest of the proposal?

:-)


> Well, part of the reason for my focusing on the trivial issue
> of what to name the basic data type is that I'm pretty happy
> with the real substance.

I agree with Ken here.

Outside trivial name-related issues or the editorial-related
problems, my only points are:

- I am not really happy that xtime_get does not return the value
of the readed clock (because dialects like
  strfxtime(buff, sizeof buf, "%c", xtime_get(0, xxx), Local_tz);
will then become very easy to write), but the current solution
is certainly almost as readable inpractice, and it avoids the *int
parameter from the first idea of Markus (that I did not like)

- similary, xtime_conv may perhaps return the result (dst),
or NULL if an error intervenes

- about xtime_delay, it should have some ways for this function
to be not supported by implementations.
Some implementations have no user-usable timers (MS-DOS comes to
my mind), so the only way to effectively implement this is
to stop any activity and wait until the main clock reaches some
point of time... This is not efficient (IMHO).

- similar with tz_error, there might be a need for
xtime_conv_error, which will sumarize the reasons why any functions
from xtime_make, xtime_break, xtime_conv or strfxtime have
previously failed (examples of reasons are: "lack of needed
informations", "source time does not exist", and the usual
cases from failed validations of the parameters, or lack of memory).

- there should be a way to determine how to size the buffer for
strfxtime without resorting to tricks (read: kludges) like
mallocating a buffer of the heap and, if the call fails, doubling
the buffer before re-issuing the call. Others similar functions
return the space needed when the s parameter is NULL. Is it worth
the need?


Anyway, all of this is pretty secondary. I shall say that I find
this proposal very attractive, and that it is easy to use *and*
very powerful.

The only remaining point I have if about procedures.
I think the best way to do is to formally present this proposal
at the WG14 meeting, at Santa Cruz, California, on October 5-9.
Unfortunately, I cannot come at such a meeting, so I cannot
"champion" it. Is somebody interested by such a role, which
is really needed if we want this proposal to be effective in
the next revision of the C standard?


Antoine