strftime calls tzset and then accesses __tzname and calls mktime. These accesses do not happen under the lock which protects the global timezone variables, so there is a data race and strftime could use unexpected timezone data.
It is unclear if POSIX actually requires that strftime calls tzset. POSIX says, “Local timezone information is used as though strftime() called tzset().” If the intent is that strftime has the same side effect as calling tzset directly, updating the tzname, daylight, timezone variables, this is a curious way of putting it, although the same language is used for localtime.
Furthermore, with our current tzset implementation, a call to tzset means that we have to access the file system on every call, to check if the timezone data file hasn't changed (if such a file is used).
Submitted Austin Groups issue: http://austingroupbugs.net/view.php?id=1125
According to the POSIX clarification, we need to behave as if strftime called tzset.
We can still make the internal use of this data race-free, fixing this bug.