Proposal: API for thread-safe time zone functions

[Jonathan Lennox]

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.

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 at cs.columbia.edu