Regarding the thread safety issue relating to getenv() in boost date_time, we have now identified the problem and it appears to be a call to putenv() elsewhere in log4cxx. putenv() is usually not bad, but here there is a call to putenv() with a string created on the stack. When the thread ends, the stack gets destroyed and further calls to getenv() cause an access violation. So the bug was not thread safety, but simply an ugly bug in log4cxx. However, the fact remains that the date_time library uses non-thread safe functions in a way that cannot be controlled by the user. boost date_time may not be the only one calling these functions, and so "wrap it in a mutex on your side" requires the user to know which calls to wrap in a mutex, and be sure that all third parties, not just boost but also log4cxx etc., using "localtime" are wrapped in the same mutex. And this assumes that all that is necessary to solve the thread safety in some implementation of "localtime" is to call "localtime" serially and never concurrently. This is operating system dependent and one of the reasons to use boost is to eliminate os-dependent code. log4cxx has fixed this already in its cvs due to a rewrite of the framework. When I mentioned it should be in a central place, this is because there are various libraries, such as spirit, that require (or required -- we're using 1.30.2) BOOST_SPIRIT_THREAD_SAFE to be defined, and so it would be nice if all "what you need to do to work in multi- threaded environments" was all in one central place, rather than forcing the user to collect bits of information on this issue from each of the various libraries. Yitzhak Sapir