Hi, When using the IANA tz data and code (version 2017B) on AIX and/or HPUX, I got core dumps. I was not able to figure out the root cause, but after I had renamed the timezone, daylight and tzname variables to something else (i.e., prefixed with olson_), the error disappeared. A similar crash happened on AIX 7.2, but in only one test case (compared to all our test cases on AIX 7.1 and HPUX 11.31). I don't have a good explanation for the different behavior between AIX 7.1 and 7.2. The tz code was incorporated into two parts of our product: 1. The tzcode was built with USG_COMPAT enabled, i.e. timezone, daylight and tzname symbols are used and incorporated into our binaries 2. The tzcode was also built into a shared library that uses another shared library that calls some of the time functions from libc (e.g. tzset(), or gettimeofday()) BTW: in our code, I'm renaming (using defines) all tz functions too, and prefix them with 'olson_'. So, at symbol level, no duplicates between system functions and TZ code functions should exist. In our code, the error happened under the following circumstances: 1. A binary of us is using the tz library (using USG_COMPAT) 2. That binary loads dynamically (with dlopen(), with RTLD_GLOBAL flag) another shared library of us, also containing the tz library 3. A 3rd party shared library was loaded by our own shared library. Also with dlopen/RTLD_GLOBAL flag. Both our binary (#1) a shared library (#2) were creating using export lists/versions scripts. None of the tz code or variables was exported. And our shared library is using a flag that forces the loader to perform 'innermost symbol resolution' (in such way that C++ exceptions still work). The 3rd party library was either the Oracle or DB2 client database library. Both perform a call to libc that triggers a time function (gettimeofday() or tzset()). The core dump happens in libc, on one of the time functions, called by the 3rd party shared library. Using IANA tz functions from our binaries, without loading 3rd party shared libraries works fine. Hypothesis: the fact that the tzcode (compiled with USG_COMPAT) changes (one of) the (libc exported) timezone, daylight, tzname, causes the time functions in libc to crash. Notes: a. making timezone, daylight, tzname static in the IANA localtime.c and added a get_xxx function did not help either. b. Building without USG_COMPAT did not help either. It is quite strange that none of these both (#a and #b) did help, but I lack time to do more research. As I now have a suitable workaround (by renaming/prefixing involved variables), it is fine for me now. This mail is just intended to inform about conflicts/core dumps, most probably related to 'similar named' variables with the system libc (and thus generate a trap on some platforms). If the tz code can get changed (ever/in the future) to prevent such conflicts, it would be great. No other action is needed (by me) for now. Regards, Kees