On Nov 1, 4:58 pm, Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote: > I'm glad to announce that the time zone support branch is ready for review.
I did a simple performance test on PostgreSQL (fetch 1000 objs with datetime field) and could not see any real performance regressions. I did the same for template rendering, and according to my tests, setting USE_TZ=True leads to around 10% slower template rendering (in a template doing nothing else than rendering 1000 datetime fields). I could not see any regressions when USE_TZ was False compared to Django trunk. So, at least according to this simple test there is nothing to worry about performance-wise. The end of the post includes the test code for reference. > 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 :) This part of the documentation raises one question: """ Unfortunately, during DST transitions, some datetimes don't exist or are ambiguous. In such situations, pytz_ raises an exception. Other :class:`~datetime.tzinfo` implementations, such as the local time zone used as a fallback when pytz_ isn't installed, may raise an exception or return inaccurate results. That's why you should always create aware datetime objects when time zone support is enabled. """ Won't this lead to web applications where errors suddenly start popping up all over the place, but only twice (or once?) a year? A setting "ON_NAIVE_DATETIMES=[do_nothing|log|error]" could be nice, at least for testing. This way you could spot the errors early on. I don't know if that would be too expensive performance wise, though. > 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. I don't see this as a major issue, except if Django needs to support this behaviour for backwards compatibility reasons. But as this is documented as a limitation, not as a "feature", this is fine as is. It would be nice to fix this in the future. For PostgreSQL, tracking the current time zone for the connection seems a bit hard - we can't rely a SET TIME ZONE is really going to be in effect, unless we also track rollbacks/commits (see #17062). And changing it for every DB query seems bad, too. One idea is to use "SELECT col AT TIME ZONE 'GMT+2' as col". This way the session time zone doesn't need to be changed. For example: > SET TIME ZONE 'UTC'; > create table testt(dt timestamptz); > insert into testt values(now()); > select dt at time zone 'GMT+2' as dt from testt; 2011-11-18 07:06:47.834771 > select dt at time zone 'Europe/Helsinki' as dt from testt; 2011-11-18 11:06:47.834771 Oracle seems to have a similar feature [1]. I don't know if other databases offer similar functionality. MySQL has probably support for something similar when using TIMESTAMP columns. But as said, I don't see this as a major issue. It would be nice to support this some day. I haven't read the code in detail, but what I have seen seems to be very good quality code. I hope to see this in trunk soon. - Anssi [1]: http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm Search for AT TIME ZONE. ---- The test code from django.core.management import setup_environ import settings setup_environ(settings) # M is a model with one text field and one datetime field. from tester.models import M from datetime import datetime from django.db import connection from django.template import Template from django.template import Context import pytz def load_data(): bulk = [] for i in range(0, 1000): bulk.append(M(f1='foob', dt=datetime.now())) M.objects.bulk_create(bulk) load_data() start = datetime.now() for i in range(0, 10): for obj in M.objects.all(): pass print datetime.now() - start print obj.dt templ = """ {% for obj in objects %} {{ obj.dt }} {% endfor %} """ t = Template(templ) c = Context({'objects': list(M.objects.all())}) start = datetime.now() for i in range(0, 10): output = t.render(c) print datetime.now() - start print 'The template generated... %s' % output[0:100] -- 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.
