On Thu, 7 Jun 2001, Jonathan Lennox wrote:
* Design the proposal as an amendment for ISO C rather than POSIX.
Wouldn't it need to be an amendment to both? I don't have either specification handy, but I was under the impression that the TZ environment variable, and tzset(), were POSIX.
Conceptually, this is at a level which is appropriate and useful for ISO C. POSIX will adopt ISO C amendments in due course. The basic interfaces for thread-safe use of timezones can be specified in ISO C, with additional features (e.g. TZ, tzset, how anything to do with threads is done) left to POSIX. (I think thread-safe interfaces will still be useful to people writing for a non-POSIX ISO C environment with threads.) The POSIX timezone strings could either be carried over to ISO C, or left to POSIX with timezone strings left implementation defined in ISO C.
What's your thought on strptime_z()? (And should there be a wcsptime_z()?)
strptime is an X/Open feature (newly in POSIX as of the Austin Group drafts) so would go in the POSIX side of these amendments. The Austin Group drafts don't seem to have a wcsptime function.
* Use an C99 snprintf-style return value (return the length of buffer required if the buffer isn't long enough) rather than what strftime currently does (return 0 if the buffer isn't long enough).
Useful enough, I suppose, but is it worth the compatibility break with strftime()?
When C99 specified snprintf's return value, this was different from some prior art that did it differently, and from swprintf (added in AMD1) which used strftime-like returns. I think providing the information for a single new allocation of the desired buffer length to suffice (rather than iterating with larger buffer sizes) is sufficiently worthwhile to make the change.
* Provide specified timezone names for both the user's local timezone and the system's local timezone.
I don't think ISO C distinguishes between these concepts, and for POSIX, getenv("TZ") should be sufficient for the former, no? I defined the NULL string as representing the latter.
If the weasel wording required to fit this in ISO C (which does rather lack the concepts involved) can be worked out, I think it would be useful to put these in. -- Joseph S. Myers jsm28@cam.ac.uk