Proposal for new ISO C 9x time API
ncm at cantrip.org
Wed Sep 16 19:10:10 UTC 1998
Markus Kuhn writes:
> I have now revised my proposal for a new <time.h> for C, which you
> can find on
My initial impressions:
I'm glad to see a new beginning in place of the "tmx" proposal, and
acknowledgement of the problems it addressed poorly or not at all.
I'm also glad to see this discussed in this forum.
While this new proposal is much, much better than tmx, it still has
some problems. They look fixable to me.
First, it doesn't entirely solve the re-entrancy problem. If an error
state and error message are to be carried around in the timezone_t
object, then a "bad" timezone_t cannot be shared across threads which
might have different locales. This part of the interface needs some
rework. Given a bad timezone_t value, I don't see how strfxtime should
indicate failure for those formats which use the time zone. An
alternative interface, in place of tz_prep and tz_error, might be:
timezone_t* tz_construct(const char *restrict tzstring,
char *msg, int maxsize)
which returns 0 for failure, and then if msg is non-null, stores a
message into it up to max_size characters in length. This way
there is never a bad timezone value to handle. (A null timezone
is already specified to be treated like UTC.)
Another problem I foresee is that there is no way, given a timezone_t
object, to retrieve the string used to construct it. This might best
be another strfxtime directive.
The names strfxtime, xtime_make, and xtime_breakup are inconsistent
and not ideally chosen. May I suggest instead
xtime_format: "To plan or arrange in a specified form"
xtime_compose: "To make or create by putting together parts or elements."
xtime_resolve: "To separate (something) into constituent parts."
respectively? (Quotes are from the Random House unabridged dictionary.)
I don't like to see the %H, %M, and %S formats restricted in their
format to only '.' and ',' decimal separators. Separate directives
(perhaps %.nH et al) that format only the fractional part would
allow users to supply any decimal separator they chose, as in
"%H:%M!%.3M" for "03:20!666". (I have seen satellite navigation
systems with stranger choices of syntax.)
Given that the format already specifies 64-bit operations on the more
commonly-used component of the time, is there any reason to restrict
the resolution of the fractional part to nanoseconds? Clock speeds
greater than 1e9 Hz will be common before this interface comes into
wide use. It may as well use (say) attoseconds, as in Bernstein's
library. The library might also define constants corresponding to
one nanosecond, microsecond, and millisecond in whatever unit is used
for the fractional part, to minimize user errors.
Typos: I believe the first paragraph describing representation of leap
seconds refers to the member "sec" in one place where it should say
"nsec". Also, the "note" text shows up in my browser in a microscopic
I'm interested in what can be done to improve its suitability for
incorporation into a future C++ standard. If the C and C++ bindings
could be described simultaneously this would save a lot of trouble
in the future.
ncm at cantrip.org
More information about the tz