This is the mail archive of the
mailing list for the glibc project.
Re: zonefile changes and long running processes.
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 02 May 2014 11:00:32 -0700
- Subject: Re: zonefile changes and long running processes.
- Authentication-results: sourceware.org; auth=none
- References: <53632771 dot 9080903 at redhat dot com> <53632B7C dot 9040201 at cs dot ucla dot edu> <53633734 dot 5010406 at redhat dot com> <53633965 dot 3010606 at cs dot ucla dot edu> <53633D96 dot 6070306 at redhat dot com>
On 05/01/2014 11:39 PM, Carlos O'Donell wrote:
Thus you must explicitly call tzset frequently and before the use
of localtime_r if you want to attempt to guarantee, as close as you
possibly can, a correctly printed time.
Does that make sense?
Sort of, though it sounds awkward: tzset is not thread-safe, so if one
thread is calling tzset other threads cannot simultaneously call
localtime_r. If the app is responsible for enforcing this constraint,
it'll be a pain for app developers. And if glibc is responsible, it'll
slow down localtime_r. I don't know what glibc really does here; do
you? (I assume it's not documented, so officially this means the app is
Another problem is that some applications call localtime on several
different time stamps and expect to get a consistent set of answers,
i.e., answers all based on a single current time zone. If localtime
invokes tzset and tzset changes the time zone in the middle of this
process, the application will get an inconsistent set of answers and may
screw up. An example is Emacs's calendar-current-time-zone function. I
suppose that such applications could be modified to use localtime_r
instead, but this could be a maintenance hassle.