Proposal for new ISO C 9x time API

[John Cowan]

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)