[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZoo6GcCQ3Geu1LSCc21FpJAQktqKLgdxSe=dXA7VPfK3Vg@mail.gmail.com>
Date: Wed, 14 Jun 2023 11:06:09 -0700
From: enh <enh@...gle.com>
To: libc-coord@...ts.openwall.com
Subject: thread-safe localtime() for an arbitrary timezone
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?
i've not done anything for Android to date because the usual answer for any
of the broken-as-designed APIs that pretend to deal with human diversity is
usually just "use icu4c instead", but this specific case does seem to come
up in contexts where full-on i18n isn't really the aim; "C.UTF-8 but in a
local timezone rather than UTC" is the much lower goal. (
https://github.com/chronotope/chrono/issues/499 is the specific motivating
example that has me thinking about this this week.)
i'm tempted to resolve the supply/demand catch-22 [for Android, at least]
here by just exposing the tzcode implementation of the netbsd functions in
Android for next year's release (we're too late for this year's release
already). but if anyone else is doing anything in this direction, i'd be
interested in increasing interoperability between libcs.
(fwiw, i see iOS has an implementation of getenv() and friends that's
supposed to be thread safe [i think they just outlaw `environ`?], but that
only solves part of the problem. afaict from grep -r for localtime and
timezone in the macOS sysroot on the laptop i'm typing this on, and the
lack of any cross-reference on the localtime man page, they don't have any
additional api in this area.)
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
