Proposal for new ISO C 9x time API

John Cowan cowan at
Wed Sep 16 19:19:35 UTC 1998

Nathan Myers wrote:

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

The tz_error function is explicitly allowed to generate its response
based on the locale at the time tz_error is called.  This eliminates
the requirement to carry around the error message in the timezone_t object.

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

Timezone_t objects aren't necessarily constructed from Posix-style strings:
they might use Olson-style long timezone names and an external database.
If you mean simply returning the original second argument to tz_prep,
I suppose that might serve some purpose.
> 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.

UTC and TAI times are only correct to 100 ns or so.

John Cowan		cowan at
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

More information about the tz mailing list