On Thursday, June 7 2001, "Paul Eggert" wrote to "lennox@cs.columbia.edu, tz@elsie.nci.nih.gov" saying:
* Is this spec compatible with Drepper's proposal? This is a relevant issue, since time zone names ought to be part of the locale. For example, where you say "EDT", a French Canadian would say "HAE". Thus, for example, for full generality it seems to me that localtime_z would need to have a locale parameter or have access to the locale somehow. Admittedly the current time zone database does not support any locale other than English, but we've seen proposals for fixing this and it will probably happen some day.
I'm pretty sure that only strftime/wcsftime need to have locale-specific information. (Especially if we drop time zone names from anything but strftime().) Actually, I suppose strptime/wcsptime might need it too, but that's a bit more confusing. I was thinking of something along the lines of strftime_zl(char *buf, size_t maxsize, const char *format, const struct tm* timeptr, const timezone_t tz, const locale_t locale); (merging strftime_z and strftime_l), but maybe that's awful...
* Conversely, if you merge Drepper's work with your proposal, then 'struct tz' should be part of his locale object, so that there is no need for a separate 'struct tz', or a separate 'localtime_z', etc. Perhaps this is too drastic (as you may not want to assume Drepper's approach), but treating TZ like we treat LC_CTYPE etc. would have real advantages if we were starting from green fields.
It seems a bit drastic for my purposes. Also, timezones feel rather different from locales to me.
* I see no reason for struct tz to make tz_name visible. If a user wants the time zone name, he can use strftime_z with the "%Z" format. Many time zones have more than two names, so it's incorrect for tz_name to have just two elements anyway.
Fair enough.
* I would drop 'tzuse', or at least make it optional and dependent on support for POSIX threads. If you drop it, you don't have to worry about threads at all; you'll simply have thread-safe functions. It's not worth the hassle of interacting with all the different thread implementations out there.
Either dependent on POSIX threads, or else a simple (rough) equivalent of tzset() without them.
* Frankly, I don't know how POSIX functions like localtime_r are supposed to interact with setting the TZ variable. It seems to me that the POSIX spec is unclear here. This murk is not your fault, but it seems to me that if you want to address the thread problem that this issue should be made crystal clear in any thread-safe spec.
Hm. What does tzcode do?
* 'strptime_z' should be marked as being POSIX-only; it needn't be available on ISO-C-only systems.
Is strptime actually even POSIX? I thought it was an extension. Or has the Austin group added it?
* What is the use of 'duptz'? Can you give an example that cannot easily be expressed without 'duptz'?
It was following Drepper's duplocale(), which was intended to make it easy to implement copy constructurs for C++ locale objects. It can be dropped easily enough.
* A nit: you mention "GMT0", but the latest POSIX draft says that "date -u" acts as if TZ is either "UTC0" or "GMT0", with "UTC0" preferred.
Fair enough. -- Jonathan Lennox lennox@cs.columbia.edu