Proposal: API for thread-safe time zone functions
eggert at twinsun.com
Thu Jun 7 20:41:56 UTC 2001
> From: Jonathan Lennox <lennox at cs.columbia.edu>
> Date: Thu, 7 Jun 2001 15:04:44 -0400 (EDT)
> > As I think about it, I think a better alternative would be parallel to
> > how setlocale() works:
> > If tzname is a null pointer, the return value shall represent
> > Coordinated Universal Time (UTC). If tzname is a string of
> > length zero, the return value shall represent the same
> > timezone as is chosen by tzset().
> We want there to be a way of getting the system time -- the equivalent of
> 'unsetenv("TZ"); tzset();'.
The null pointer sounds like a good way to do that, as it
"feels like" having an unset TZ.
We shouldn't use the empty string for that, as TZ='' has a special
meaning to the tz code (namely, assume GMT without leap seconds,
regardless of whether the underlying system uses leap seconds), and
newtz("") should use this interpretation rather than supply its own.
> That said, I suppose defining the interface such that tzset() doesn't depend
> on "TZ" is a good idea. (I had thought that tzset() and "TZ" were both
> POSIX, but is one of them ANSI?)
Neither is in the C standard.
I don't know what you mean by "tzset() doesn't depend on 'TZ'" but I
don't think we should modify tzset's specification. tzset is an
anachronism. If you can assume the current POSIX interface, you don't
need tzset at all. The only reason we should mention tzset at all is
to specify how it interacts (if at all) with the new features.
(Perhaps this is what you were saying....)
> The motivation for this section is to allow existing code which uses the
> time functions to work with thread-safe timezones. This model allows you,
> e.g., to set a thread timezone and then call a function in an external
> library to which you don't have source.
Suggestion: create a "rationale" section and put the above comment
into that section. (Also, fold all our other comments into the
rationale while you're at it. :-)
More information about the tz