Proposal for new ISO C 9x time API

[Nathan Myers]

Antoine Leca writes:
 > 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?

Any string that will re-create the same time zone object is 
sufficient.  The string used to construct it is the simplest to
(re-)produce.

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

This does not follow.  When the timezone_t object is freed,
the string storage can be freed as well.  Note that strfxtime
(or, better, xtime_format) does not return pointers to internal
storage.

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

So, then don't localize it.  Or define "localizing it" to mean 
nothing is changed in it.  I don't see the problem.

Nathan Myers
ncm at cantrip.org