Proposal: API for thread-safe time zone functions

Joseph S. Myers jsm28 at
Thu Jun 7 18:42:01 UTC 2001

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

> > * 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 at

More information about the tz mailing list