From: Jonathan Lennox <lennox@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. :-)