[tz] [libc-coord] thread-safe localtime() for an arbitrary timezone

[enh]

On Wed, Jun 21, 2023 at 2:18 PM Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 2023-06-21 12:50, enh wrote:
> > my preference would be for timezone_t to be more like DIR...
> >
> > typedef struct DIR DIR;
>
> Although that would also work, that's not how NetBSD did things when it
> introduced timezone_t in NetBSD 6.0 (2012), and tzcode copied this part
> of NetBSD in tzdb 2014g. I doubt whether we should change the meaning of
> timezone_t at this point, as it'd be too much backward-compatibility
> hassle.
>
> We could use a different name, though, for the struct. How about if we
> change this line in tzcode private.h:
>
>    typedef struct state *timezone_t;
>
> to the following?
>
>    typedef struct tm_timezone *timezone_t;
>
> and change all other instances of "struct state" to "struct tm_timezone"?
>
> This would let users write "struct tm_timezone *" and "timezone_t"
> interchangeably. The name tm_timezone, like timezone_t, is reserved by
> POSIX when you include <time.h>[1], so if the <time.h> implementation
> uses this name it won't break any conforming programs.
>

(i just checked and NetBSD does have `typedef struct __state *timezone_t;`
in its <time.h>. my objection to that is that the compiler will actually
use the underlying name in error messages, which is less than helpful if
the names aren't close. so having s/state/tm_timezone/ seems like a step
forward even just in that regard!)

up to you (especially since my #define in "private.h" is unlikely to be
much of a maintenance burden), but "i'd use this" (if only to get rid of my
#define)...


> [1]:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02_02
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20230621/fe3be1b0/attachment.htm>