This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author adamwill
Recipients adamwill, belopolsky
Date 2017-04-12.22:37:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Hmm, after a bit more poking I found this:


Although in many cases, changing the TZ environment variable may affect the output of functions like localtime() without calling tzset(), this behavior should not be relied on."

It seems like that's kinda what we're dealing with here. If I extend my tests to change TZ, call the test function, then call `time.tzset()` and call the test function again, the *second* call to the test function gives the different result, i.e. the `time.tzset()` call does what it claims and changes Python's conception of the 'current' timezone.

So while that note has been there all along, it seems like the behaviour actually changed between 3.5 and 3.6, and a change to 'TZ' is now less likely to be respected without a `tzset()` call. But given the doc note, perhaps that can't be considered a bug.

anaconda doesn't call `time.tzset()` anywhere at present. It's also multi-threaded, so making sure all the threads call `time.tzset()` after any thread has changed what the 'current' timezone is will be lots of fun to implement, I guess :/
Date User Action Args
2017-04-12 22:37:09adamwillsetrecipients: + adamwill, belopolsky
2017-04-12 22:37:09adamwillsetmessageid: <>
2017-04-12 22:37:09adamwilllinkissue30062 messages
2017-04-12 22:37:09adamwillcreate