Re: zonefile changes and long running processes.

["Carlos O'Donell" <carlos at redhat dot com>]

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
conversion.

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.

Cheers,
Carlos.