Proposal for new ISO C 9x time API

[Nathan Myers]

Markus Kuhn writes:
 > I have now revised my proposal for a new <time.h> for C, which you
 > can find on
 > 
 >   http://www.cl.cam.ac.uk/~mgk25/c-time/

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 
font.

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.

Nathan Myers
ncm at cantrip.org