Proposal: API for thread-safe time zone functions

[Joseph S. Myers]

On Thu, 7 Jun 2001, Garrett Wollman wrote:

> All of these suggestions are essentially orthogonal to the main issue
> of re-entrant, thread-specific time conversions.  I suggest that
> Mr. Lennox's proposal is much more likely to be gain concensus than
> any changes to the underlying interfaces.

If designing better timezone interfaces, we should try to get them right
rather than needing another change later.  As long as we don't try to
change time_t, consensus shouldn't be a great problem.

Some more points:

* Better timezone interfaces were extensively discussed on the tz list in
September/October 1998, and that discussion should be taken into account.
It isn't clear whether this proposal has done so.
* Better time interfaces were listed as one possible item for an amendment
to C99 (after the problematic changes in some C9X drafts were backed out).
Antoine Leca may know the current ISO status of this.
* A list for discussing these interfaces was then set up, though it hasn't
had much discussion, but it would be the appropriate place for discussing
these interfaces.  c-time at list.cr.yp.to, subscription by empty message to
c-time-subscribe at list.cr.yp.to.

> > * Provide specified timezone names for both the user's local timezone and
> > the system's local timezone.
>
> In the context of POSIX, there is no such distinction.  (Of course,
> the timezone library is able to make a distinction.)

The user's time is that in TZ, the system time is that when TZ is unset.
In the ISO C context, defined names for these should be provided.  The
system time is for use of programs controlling access to resources whose
cost depends on the system's local time.

-- 
Joseph S. Myers
jsm28 at cam.ac.uk