Revision of ISO C 9x <time.h>

Markus Kuhn Markus.Kuhn at
Sat Aug 22 20:51:38 UTC 1998

The new ISO C draft is on <>.

I think, the following message might be of interest to many here:

------- Forwarded Message
Date: Sat, 22 Aug 1998 21:00:08 +0100
To: David R Tribble <david.tribble at>,
        Antoine.Leca at, kuhn at
From: "Clive D.W. Feather" <clive at>
Reply-To: "Clive D.W. Feather" <clive at>
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>
Tel: +44 1733 705000 | (on secondment from      | Home: <cdwf at>
Fax: +44 1733 353929 |  Demon Internet)         | <>
Written on my laptop; please observe the Reply-To address

------- End of Forwarded Message

More information about the tz mailing list