Revision of ISO C 9x <time.h>
Markus.Kuhn at cl.cam.ac.uk
Thu Sep 3 14:50:38 UTC 1998
The new ISO C draft is on <ftp://dkuug.dk/JTC1/SC22/wg14/index.html>.
I think, the following message might be of great interest to many here.
I hope Clive has in the meantime managed to join the tz list, such that
we can discuss proposals here.
------- Forwarded Message
From: "Clive D.W. Feather" <clive at demon.net>
Subject: It's about time
[sorry for the bad joke]
I'm sorry I've taken so long to get back to people about this. This
email is going to all the people who have expressed to me an interest in
the C9X time functions.
C9X CD2 (aka the FCD) is now published (it can be found on the DKUUG web
site). It basically contains the same material in <time.h> as CD1 did,
though a few minor errors have been corrected and Keld's %O and %E
modifiers have appeared.
Everyone who's written to me has expressed dissatisfaction with some
part or other of the current situation. Therefore I have a rather
radical proposal to make: I suggest we write a complete new <time.h>
section that addresses all our issues, and arrange for at least two, and
preferably three or more, National Bodies to submit it as part of their
response to CD2. I'm willing to act as the core editor for this work,
- people will write full pieces of text for me to drop in as needed;
- people won't object to my use of editorial powers to tidy up and keep
the wording consistent.
I can provide web space where I will keep the working drafts.
I suggest we start with what's in CD2 as a common base, though being
ready to drop pieces if that's what we agree. In the meantime, here's
all the issues that I'm aware of that our text would need to handle:
(1) Clear definition of canonicalisation of times.
(2) Unambigous mechanisms for converting between UTC and TAI, and
between time zones, and for determining which is in use.
(3) Clearer definitions of things like strftime conversions (all of
these are in CD2, so this is a no-op).
(4) Ability to determine the precision of times (a ticks per second
macro, perhaps). This should be guaranteed to be <= 1 second over some
(5) Ability to determine the range of time_t, with guaranteed minimum
(6) A member in struct tmx for access to subsecond resolution, and
possibly new formats to access it.
(7) The meaning of struct tm to remain source and binary compatible with
(8) Clearer definition of what struct tm[x] values must be handled by
(9) All new functions to be re-entrant.
(10) Rethink future expandibility of struct tmx.
(11) Portable form for transferring time values between programs and
Anything else ?
I've no objection to this message having wider circulation, but only to
people who aren't going to require more education than there's time for.
Clive D.W. Feather | Regulation Officer, LINX | Work: <clive at linx.org>
Tel: +44 1733 705000 | (on secondment from | Home: <cdwf at i.am>
Fax: +44 1733 353929 | Demon Internet) | <http://i.am/davros>
------- End of Forwarded Message
More information about the tz