Change how we set the timezone after loading from siteconfig.
Review Request #3794 — Created Jan. 26, 2013 and submitted
Change how we set the timezone after loading from siteconfig. We had a strange bug that resulted from how we set the timezone after loading it from the siteconfig settings. We followed Django's model of setting os.environ['TZ'] and calling time.tzset(), but this ended up causing some interesting problems. When running the devserver and using rbssh through Review Board, rbssh would crash and the devserver would reload. This was due to the default timezone being used at launch and the autoreload thread being spun up and using that timezone for all Python module mtime verification. When rbssh was invoked, it'd import paramiko, which imported Crypto.Random, which had to be extracted first before the bundled native libraries could be used. These libraries would be saved with a time calculated from the value of os.environ['TZ'], but the autoreload thread would calculate from the default reviewboard.settings.TIME_ZONE, causing a mismatch in expected values and triggering an immediate reload of the devserver, which killed off the connection to rbssh, breaking stdin/stdout and causing a crash. Now we don't touch os.environ['TZ']. We are going to say that it will just mirror the actual TIME_ZONE value in settings. Instead, we'll use Django's timezone.activate function to have that particular thread use the new timezone for all of Django's functions. This means functions like time.localtime will take the default (UTC) timezone into account rather than the timezone set by the admin, but anything that's using Django's timezone functions will do the correct thing. See this post for more information: http://blog.chipx86.com/2013/01/26/weird-bugs-django-timezones-and-importing-from-eggs/
Followed my repro case for repository verification that continually broke. It works now. All unit tests in Djblets and Review Board pass.