Can try to get it in for 1.0. Might slip.

(No comment was entered for this change.)

Added in r1925.

This doesn't quite work for me.  Changing the value doesn't seem to make any impact.
 I've tried to unravel it because it seems like there are a couple of issues.

1. There appears to be a bug in djblets/siteconfig/django_settings.py.  TIME_ZONE is
listed twice, and I think it is referencing the one with locale_time_zone which is
incorrect (admin/forms.py is locale_timezone without an underscore).  I'm not exactly
sure which one is correct, it's not clear to me how djblets is updating
django.conf.settings.

2. Due to the way the timezone is set (in django.conf it updates os.environ['TZ'] and
calls tzset), it's not picking up the change due to the way djblets is overriding
django.conf.settings.  In the debugger, I can see django.conf.settings.TIME_ZONE is
correct (after fixing the issue in #1), but os.environ['TZ'] is not updated.  It
doesn't work even if I restart the webserver.

Try upgrading your Djblets. Both issues were fixed the same day this went in. I
probably just screwed up on setting the dependency for the new version.

I think I have the latest (r12061).  I can at least see in django_settings.py that in
apply_django_settings it's going to matter what order the two TIME_ZONE settings show
up (it takes the last value).  So if it happens to come out of the dictionary as 

'locale_timezone':             { 'key': 'TIME_ZONE',
                                     'deserialize_func': str },
'locale_time_zone':            'TIME_ZONE',

or

'locale_time_zone':            'TIME_ZONE',
'locale_timezone':             { 'key': 'TIME_ZONE',
                                     'deserialize_func': str },

the last one will win.  It happens to come out in the right order on my system (the
second case), but that is not very reliable.

Also, due to the way that the siteconfig middleware works, just setting TIME_ZONE on
the django settings object will not affect the system timezone.  The Settings object
only does that during __init__.  It will need to update the environment variable and
call tzset somehow.

Okay, so I use git for my management, and it looks like I accidentally committed to
"master" instead of my topic branch for this. So I saw it on "master" and assumed
that meant I pushed it to SVN, which I didn't. I just now took care of this, and it
should be fixed in r12062. Let me know if you hit any issues.

Ah, that's it.  That works, thanks!

So far there is only one global setting in the admin page.
Are there any plans on having per-user timezones?

That would be very useful for cross-world developement.