On Jun 20, 2023, at 7:16 PM, Paul Gilmartin via tz <tz@iana.org> wrote:
( the Archives of this thread seem incomplete.)
tz mailing list archives, or lib-coord: https://www.openwall.com/lists/libc-coord/2020/01/30/1 archives? The former are incomplete because the thread didn't start on the tz mailing list; the first message, to libc-coord, was linked from Paul Eggert's message to tz in this thread: https://www.openwall.com/lists/libc-coord/2023/06/14/1
On 6/20/23 15:00:29, enh via tz wrote:
... We could rename 'struct state', but I'm a bit lost as to what the problem is, as I don't see mention of 'state' or 'timezone_t' in openbsd/lib/libc/time/wcsftime.c. Although there is a 'struct state' in openbsd/lib/libc/time/localtime.c I assume you're replacing that with tzcode's localtime.c somehow.
(Replying mostly to the Subject:) A thread-safe localtime() seems impractical. localtime() depends on the environment variable TZ. If concurrent threads set different values of TZ the results will be unpredictable. The same applies to localtime_r().
If concurrent thread set different values of TZ, perhaps the concurrent threads should use a reentrant localtime_z() routine, possibly with a different name, as has been proposed in a number of places, including in this list back in 2001: http://mm.icann.org/pipermail/tz/2001-June/011636.html That requires making such a routine common on multiple platforms, of course.... And, in fact, in the first message in the thread, the author said is anyone aware of any standardization work in this area? i know netbsd has tzalloc()/localtime_rz()/tzfree() (and tzcode has implementations), but they're the only ones who've shipped anything, right? and there's no in-progress work on any alternative? So the proposal there is for localtime_rz(), taking a "time zone" structure, or pointer to same, provided by tzalloc() and freed by jtzfree(), rather than something that looks at TZ. (Perhaps the title was a bit misleading, and should have said "lcoaltime() equivalent".)