In today's multi-threaded world, is changing an environment variable, calling tzset(), calling mktime(), changing the env variable back, and calling tzset() again really the best way to solve this problem?
Stephen, It's obviously not ideal. I added some words pointing out that it's not thread-safe. But, I have no further idea for changes. Do you? Cheers, Michael
I'm not sure why the manpage documents how to not use the function (obviously, documenting *why* not to use it makes sense.) If there's honestly no good way to emulate timegm() in a threadsafe manner, should its use really be discouraged?
The Gnu glibc documentation has something like this in the portability notes. Often the genesis of comments when there's a strange disclaimer in the manpage :) I guess I'd suggest the page emphasize the UTC aspect and mention the threadsafe issue, and stop there - not try to document a workaround.
Okay--you two convinced me. I killed the sample timegm() implementation and added mention of UTC. Thread-safety issues are covered already in ATTRIBUTES.