Hello, I'm glad to announce that the time zone support branch is ready for review.
Review the changes: https://bitbucket.org/aaugustin/django/compare/..django/django Clone the branch: hg clone https://bitbucket.org/aaugustin/django Play with the demo app: hg clone https://bitbucket.org/aaugustin/django-tz-demo The docs are supposed to explain everything you need, and I described many design decisions in my weekly check-ins, so I'm purposefully keeping this email short on details :) Finally here's a teaser: http://myks.org/stuff/django-tz-demo-2.png ---- During this project, most things went according to the initial plan. There is only one outstanding issue that I know of. `QuerySet.dates()` operates in the database timezone, ie. UTC, while an end user would expect it to take into account its current time zone. This affects `date_hierarchy` in the admin and the date based generic views. The same problem also exists for the `year`, `month`, `day`, and `week_day` lookups. Under PostgreSQL, provided the current time zone has a valid name (e.g. it's provided by pytz), we could temporarily set the connection's timezone to this time zone and restore it to UTC afterwards. With other backends, I can't think of a simpler solution than fetching all values and doing the aggregation in Python. Neither of these thrills me, so for the time being, I've documented this as a known limitation. Best regards, -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
