[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170609121502.GO1627@brightrain.aerifal.cx>
Date: Fri, 9 Jun 2017 08:15:02 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: detect timezone changes by monitoring /etc/localtime
(like glibc)
On Fri, Jun 09, 2017 at 05:15:40PM +1000, Patrick Oppenlander wrote:
> During some recent testing I came across a bug when adjusting timezones on an
> embedded system by changing /etc/localtime. The cause ended up being a
> behavioural difference between glibc and musl.
This difference is intentional; I believe there are past discussions
in the list archives.
Aside from the glibc behavior giving abysmal performance (syscalls on
every time operation), there's a more fundamental issue of usability
of the results. A common important idiom with time functions is to
perform several operations together in succession to get a result --
for example, obtain the current time as time_t, format it with
localtime[_r], make some adjustment e.g. for a relative time, then
call mktime to convert back to time_t. Such operations rely on the
time zone being consistent for each suboperation, which is true as
long as the application does not modify its own environment, but only
assuming libc doesn't impose asynchronous changes on the timezone.
In order for asynchronous timezone changes to be safe, the API would
have to be such that you make one call to get the current timezone,
then pass it as an argument to functions depending on the timezone, so
that the application has control of which timezone is getting used in
each call.
Rich
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.
