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 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@cantrip.org