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. Markus ------- Forwarded Message From: "Clive D.W. Feather" <clive@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, provided: - 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 range. (5) Ability to determine the range of time_t, with guaranteed minimum limits. (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 C89. (8) Clearer definition of what struct tm[x] values must be handled by implementations. (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 implementations. 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@linx.org> Tel: +44 1733 705000 | (on secondment from | Home: <cdwf@i.am> Fax: +44 1733 353929 | Demon Internet) | <http://i.am/davros> ------- End of Forwarded Message