This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: zonefile changes and long running processes.

On 05/02/2014 02:21 AM, Paul Eggert wrote:
> Carlos O'Donell wrote:
>> What about the a polling design using tzset?
> I'm a bit fuzzy about what that design would be.  That being said,
> won't having tzset poll be likely to fail in a high-performance
> application that uses localtime_r instead of localtime?  localtime_r
> doesn't call tzset.

The design would require the process to call tzset frequently
to re-read the timezone information. This can be done from some
event thread, or just before it's used by other functions. Our 
current tzset code will stat the file to see if it changed and 
reload it.

While localtime says it acts as-if it called tzset, and our
internal implementation does that, you are right in that localtime_r,
per POSIX doesn't say anything about calling tzset. The glibc
implementation uses this to optimize out the reloading of the zonefile.

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?

So the zonefile changing won't get noticed until you call tzset
again and it's always the applications responsibility to do so?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]