zonefile changes and long running processes.

[Paul Eggert]

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

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.