Proposal for new ISO C 9x time API
cowan at locke.ccil.org
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 http://www.ccil.org/~cowan cowan at ccil.org
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