Proposal: API for thread-safe time zone functions
lennox at cs.columbia.edu
Thu Jun 7 19:15:59 UTC 2001
On Thursday, June 7 2001, "Paul Eggert" wrote to "lennox at cs.columbia.edu, tz at 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.
> * 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
> * 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"
lennox at cs.columbia.edu
More information about the tz