This is the mail archive of the
mailing list for the glibc project.
Re: zonefile changes and long running processes.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 02 May 2014 19:28:07 -0400
- 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> <5363DD40 dot 2040408 at cs dot ucla dot edu>
On 05/02/2014 02:00 PM, Paul Eggert wrote:
> 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 responsible....)
That is not correct, tzset is MT-safe, and documented in the glibc
manual as such.
Having tzset be MT-safe will not slow down localtime_r because that
function is not required by POSIX to act as-if it called tzset,
only localtime has that requirement.
Did I miss something?
> 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.
Applications calling localtime have never been guaranteed a consistent
timezone since it was implied tzset is called ant tzset may update the
timezone to the latest installed zoneinfo. This is always the way it
has been in glibc and I think it's the only way it should work in order
to support long-running processes having the right zoneinfo for
I think at this point you've answered my initial question.
Answer: Use of tzset in a long-running process is *the* way to keep
the zoneinfo udpate during upgrades.