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