Date-based generic views use naive datetime objects

[Mike Yumatov]

Some date-based generic views (MonthArchiveView, WeekArchiveView, DayArchiveView, TodayArchiveView, DateDetailView) raise time zone warnings if USE_TZ because of using naive datetime objects and date objects in _date_from_string, _month_bounds and _date_lookup_for_field from django.views.generic.dates module.

[Aymeric Augustin]

The warning is a symtom of the actual problem, which is that a "day" or "month" isn't a well defined period of time unless a time zone is also specified.

This problem is covered by #17260.

[Aymeric Augustin]

Discussion here: ​https://groups.google.com/forum/#!topic/django-developers/ZUWOzkj3Vlk

[Aymeric Augustin]

I'm reopening this because some parts may be fixed by using date ranges instead of year/month/day lookups, similar to r17670.

[Aymeric Augustin]

Fixed in 78ba9670af373f5261f95d6560bfd08425adcaad.

Now, date-based generic views display objects consistently in the current time zone. However, date_list is still off — that's #17260.

[Aymeric Augustin]

I'm tempted to backport this commit to 1.4.X. The queryset returned by YearView is wrong when time zone support is enabled, which I would have considered a release blocker for 1.4.

[Aymeric Augustin]

I've written the patch (see attachement), but for the tests to pass, I'd have to backport 46b082e05ccedffeb623028caf70adbaba7bce6f first.

I feel that these changes are quite large for fixing a minor bug (the results are off by the UTC offset only for the year view).

Unless someone's strongly in favor of backporting these two commits, I'll leave it there.

[Fantomas42]

Hi aaugustin,

I'm strongly in favor of backporting these two commits.

Because without these commits, I cannot complete my migration process for enabling the time zone support without warnings when I run my test suite.

I make an intensive usage of the dates based generic views, that's why I'm doing this request.

Regards

[Aymeric Augustin]

I tried backporting both changesets and still I got two test failures.

======================================================================
FAIL: test_aware_datetime_date_detail (regressiontests.generic_views.dates.DateDetailViewTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/myk/Documents/dev/django-trunk/django/test/utils.py", line 205, in inner
    return test_func(*args, **kwargs)
  File "/Users/myk/Documents/dev/django-trunk/tests/regressiontests/generic_views/dates.py", line 530, in test_aware_datetime_date_detail
    self.assertEqual(res.status_code, 200)
AssertionError: 404 != 200

======================================================================
FAIL: test_aware_datetime_day_view (regressiontests.generic_views.dates.DayArchiveViewTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/myk/Documents/dev/django-trunk/django/test/utils.py", line 205, in inner
    return test_func(*args, **kwargs)
  File "/Users/myk/Documents/dev/django-trunk/tests/regressiontests/generic_views/dates.py", line 456, in test_aware_datetime_day_view
    self.assertEqual(res.status_code, 200)
AssertionError: 404 != 200

Warnings can be silenced with warnings.filterwarnings if they really bother you, until you upgrade to Django 1.5...

[fantomas42@…]

Ok aaugustin,

thank you for the information and for your try of a backport.

For the now I will disable the time zone support in my test cases where dates based views are involved.

Regards