#86 libical messes with timezone, affecting other threads


It's a forwarded bug from Debian BTS:

icaltime_as_timet_with_zone() sets $TZ before calling libc functions to
do some time calculations. In a multithreaded program that interferes
with other programs which fetch local time, including syslog().

The library shouldn't be messing with the processes' global timezone in this way.


  • Allen Winter

    Allen Winter - 2012-03-13

    According to the in-line documention,

    /* If you use set_tz(), you must call unset_tz() some time later to restore the
    original TZ. Pass unset_tz() the string that set_tz() returns. Call both the functions
    locking the tzid mutex as in icaltime_as_timet_with_zone */

    For more information please read icaltime.c in the libical source code.
    Too bad libical doesn't provide real user documentation.

    So I guess you're calling program needs to do some mutex locking.

    Fathi: Please pass this on to the original bug reporter and let me know if I can close this.

  • David Woodhouse

    David Woodhouse - 2013-06-12

    It's worse than that. Any call to setenv() or putenv() in a threaded environment is liable to make other threads crash if they do anything that calls getenv(). And the list of functions which use getenv() is quite long: see http://sourceware.org/bugzilla/show_bug.cgi?id=5069#c9

    If libical uses putenv() or setenv(), then libical is fundamentally unsuitable for use in a threaded environment. It's that simple.

    A patch along these lines should fix it for systems which have timegm().

  • Allen Winter

    Allen Winter - 2013-07-06

    Good idea.
    I think what I'll do is copy in a version of the timegm.c to the library so all platforms can have it. then trash set_tz and unset_tz.

  • Allen Winter

    Allen Winter - 2015-06-02

    fyi, this is done now in the official github version. using the timegm idea.

  • Allen Winter

    Allen Winter - 2015-06-02
    • status: open --> closed-fixed
    • Group: -->

Log in to post a comment.