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

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