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@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)