Proposal: API for thread-safe time zone functions

[Paul Eggert]

> From: Jonathan Lennox <lennox at cs.columbia.edu>
> Date: Thu, 7 Jun 2001 12:09:33 -0400 (EDT)

> * Are people interested in this?
> * Would people be interested in seeing the resulting code?
> * Would people be interested in helping write the code?
> * Would the resulting code (assuming it's written sensibly) be
>   acceptable/appropriate for incorporation into tzcode?

Yes, several people have proposed something along those lines.
(I'm one of them -- see <http://www.twinsun.com/tz/timeapi.html>.)
However, nobody has gotten anything running yet.  Part of the problem
with many of the proposals (mine included) is that they're perhaps too
ambitious.  There are a lot of problems with the existing interfaces,
and it's a pain to solve them all at once.

> * Do people think that my proposal is a sensible API?

Here are some thoughts:

* 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.

* 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.

* 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.

* 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.

* 'strptime_z' should be marked as being POSIX-only; it needn't be
  available on ISO-C-only systems.

* What is the use of 'duptz'?  Can you give an example that cannot
  easily be expressed without 'duptz'?

* 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.


> Date: Thu, 7 Jun 2001 17:30:58 +0100 (BST)
> From: "Joseph S. Myers" <jsm28 at cam.ac.uk>
> 
> * Don't touch how timestamps are represented (any interface can be adapted
> to use any time_t replacement that gets agreed).

Presumably if we have an xtime_t, then the xtime_t functions will
address all the issues Lennox raises, because they'll have merged
or subsumed his ideas.

> * Provide a struct tm replacement with (a) subsecond resolution and (b) a
> proper field indicating which repetition of a repeated timestamp is
> referred to (A/B in German time notation), rather than the inadequate
> indication of whether the time is in daylight savings.
> * Provide four conversion functions: between time_t and broken down times,
> in either direction, and equivalents of strftime and wcsftime.  Don't
> duplicate other functions such as asctime that can easily be replicated.
> * Use an C99 snprintf-style return value (return the length of buffer
> required if the buffer isn't long enough) rather than what strftime
> currently does (return 0 if the buffer isn't long enough).

These changes all sound reasonable to me -- though they make the
proposal more ambitious.  If we go down this route, though, we should
definitely look at Kuhn's and my proposals (both of which are too
ambitious, in my opinion).  I could try to merge the three, or perhaps
you'd like to take a crack at it.

> * Provide specified timezone names for both the user's local timezone and
> the system's local timezone.

Doesn't his proposed API already do this, with newtz(getenv("TZ")) and
newtz(NULL)?