Proposal: API for thread-safe time zone functions

[Jonathan Lennox]

On Thursday, June 7 2001, "Joseph S. Myers" wrote to "Jonathan Lennox, <tz at elsie.nci.nih.gov>" saying:

> Have you looked at Markus Kuhn's proposal at
> 
> http://www.cl.cam.ac.uk/~mgk25/c-time/
> 
> and the other ones linked to from there?

No, I hadn't.  It's interesting -- he has some of the same ideas I had, but
trying to solve some problems that are rather larger in scope.

I was trying to solve a much smaller problem -- making the minimal changes
to existing functions needed in order to get re-entrant timezone support.

> My recommendations:
> 
> * Design the proposal as an amendment for ISO C rather than POSIX.

Wouldn't it need to be an amendment to both?  I don't have either
specification handy, but I was under the impression that the TZ environment
variable, and tzset(), were POSIX.

> * Don't touch how timestamps are represented (any interface can be adapted
> to use any time_t replacement that gets agreed).

Agreed.

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

I think this is orthogonal to what I'm looking at.  I agree it's a good idea
in principle, but I don't think I have the expertise to do it in practice.

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

Fair enough.  Also a good point about the wide versions.

What's your thought on strptime_z()?  (And should there be a wcsptime_z()?)

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

Useful enough, I suppose, but is it worth the compatibility break with
strftime()?

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

I don't think ISO C distinguishes between these concepts, and for POSIX,
getenv("TZ") should be sufficient for the former, no?  I defined the NULL
string as representing the latter.

-- 
Jonathan Lennox
lennox at cs.columbia.edu