I just did an initial scan through: https://bitbucket.org/aaugustin/django/compare/..django/django and this looks like a great piece of work.
I do think a better label than "value" could be used for the thread.local for the current timezone, as this is really a thread global - something less ambiguous and conflict prone would be better IMO. Also an explicit link to the activate command from the section where you introduce the current time zone concept. Perhaps with a simple code example of how you would set current time per user in a view. https://bitbucket.org/aaugustin/django/compare/..django/django#chg_docs/topics/i18n/timezones.txt_newline109 Was a threading.local the only way to do this - I'm sure you've given it some thought - there are relatively few uses of thread locals in Django - translation being one. If the timezone were stored on the current request, would that not be available to most places in django code that need TZ within the current thread? On Oct 30, 6:45 am, Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote: > Initially, I considered writing a script to automatically shift timestamps in > the database backends that need it, to ease the migration of existing > projects to USE_TZ=True. Upon further thought, I'm reluctant to mess with > people's databases, even with a big fat disclaimer. If I write such a script, > I'll upload it to djangosnippets. I think a very brief outline of the steps required for migration may be worthwhile in the release notes. -Preston -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
