Proposal for new ISO C 9x time API

[Antoine Leca]

Nathan Myers wrote:
> 
> Markus Kuhn writes:
>  > Nathan Myers wrote on 1998-09-16 19:10 UTC:
>  > > A problem I foresee is that there is no way, given a timezone_t
>  > > object, to retrieve the string used to construct it.
>  >
>  > Which would mean that we have to force the implementor to store the
>  > original string. Is this really necessary?
> 
> Yes, it's necessary.

What is the need? A string to be able to re-establish the same
timezone later, perhaps in another program (operating on the same
machine, of course)? Or really the same string used on input?

The first API will return, as does setlocale() today, some
string suitable for future use of tz_alloc.  It requires a
static back pointer in the internal datas.  But it will return
":America/New_York" if you send "US/Eastern".  Bad? Wrong? Right?

The second will allocate storage to hold the string.
And there will be no way to reclaim it when the timezone_t
object will be freed.  And also, this is some form of
wasting in small implementations.

If I see needs for the former, I have problems with the later.
But I may be wrong.


Also, the output of strfxtime is subject to localization. 
But the string passed to tz_alloc is not, IMHO, a data that
*should* be localized.  How should that be handled?


Antoine