Problems with date-based generic views when USE_TZ=True
188 views
Skip to first unread message
Mike Yumatov
Apr 27, 2012, 8:51:54 AM4/27/12
to django-d...@googlegroups.com
Hi!
I wrote a ticket about time zone warnings in date-based generic views: https://code.djangoproject.com/ticket/18217
After some research, I understand that there are more problems with this views, than I thought at first. django.views.generic.dates module uses aware and naive datetime objects together, which breaks all date-based views except YearArchiveView.
Let's have, for example:
- America/Chicago as TIME_ZONE
- an article, published at 2012-12-31 23:00:00 in local time zone (2012-01-01 05:00:00 UTC)
- an url /articles/{year}/ which returns list of articles for requested year
- an url /articles/{year}/{month}/ which returns list of articles for requested month
As I understand, year and month must be in UTC in urls, or date_list from all date-based generic views is useless, because it contains dates in UTC.
So, our article must be in /articles/2012/ and in /articles/2012/01/. But it won't be in /articles/2012/01/, because MonthArchiveView will use datetime.date objects, which will be treated as naive datetime.datetime object by ORM, and local time zone will be used.
The same thing is true for DayArchiveView, TodayArchiveView and DateDetailView.
This issue affects trunk and 1.4 versions of Django.
--
Mike Yumatov
I wrote a ticket about time zone warnings in date-based generic views: https://code.djangoproject.com/ticket/18217
After some research, I understand that there are more problems with this views, than I thought at first. django.views.generic.dates module uses aware and naive datetime objects together, which breaks all date-based views except YearArchiveView.
Let's have, for example:
- America/Chicago as TIME_ZONE
- an article, published at 2012-12-31 23:00:00 in local time zone (2012-01-01 05:00:00 UTC)
- an url /articles/{year}/ which returns list of articles for requested year
- an url /articles/{year}/{month}/ which returns list of articles for requested month
As I understand, year and month must be in UTC in urls, or date_list from all date-based generic views is useless, because it contains dates in UTC.
So, our article must be in /articles/2012/ and in /articles/2012/01/. But it won't be in /articles/2012/01/, because MonthArchiveView will use datetime.date objects, which will be treated as naive datetime.datetime object by ORM, and local time zone will be used.
The same thing is true for DayArchiveView, TodayArchiveView and DateDetailView.
This issue affects trunk and 1.4 versions of Django.
--
Mike Yumatov
Aymeric Augustin
Apr 27, 2012, 1:21:13 PM4/27/12
to django-d...@googlegroups.com
Hi Mike,
On 27 avr. 2012, at 14:51, Mike Yumatov wrote:
> I wrote a ticket about time zone warnings in date-based generic views: https://code.djangoproject.com/ticket/18217
It isn't necessary to notify django-developers when you create a ticket; that's the job of django-updates.
> After some research, I understand that there are more problems with this views, than I thought at first. django.views.generic.dates module uses aware and naive datetime objects together, which breaks all date-based views except YearArchiveView.
>
> Let's have, for example:
> - America/Chicago as TIME_ZONE
> - an article, published at 2012-12-31 23:00:00 in local time zone (2012-01-01 05:00:00 UTC)
> - an url /articles/{year}/ which returns list of articles for requested year
> - an url /articles/{year}/{month}/ which returns list of articles for requested month
>
> As I understand, year and month must be in UTC in urls
They are in local time in the default time zone.
> or date_list from all date-based generic views is useless, because it contains dates in UTC.
I'm not sure I understand your point there.
> So, our article must be in /articles/2012/ and in /articles/2012/01/. But it won't be in /articles/2012/01/, because MonthArchiveView will use datetime.date objects, which will be treated as naive datetime.datetime object by ORM, and local time zone will be used.
This is an ill-defined problem, and also a hard one.
The behavior you're describing is the expected behavior, it's mostly backwards compatible and in my opinion it's the least unreasonable option.
See also :
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#faq
http://groups.google.com/group/django-developers/browse_thread/thread/cf0423bbb85b1bbf
Best regards,
--
Aymeric.
On 27 avr. 2012, at 14:51, Mike Yumatov wrote:
> I wrote a ticket about time zone warnings in date-based generic views: https://code.djangoproject.com/ticket/18217
> After some research, I understand that there are more problems with this views, than I thought at first. django.views.generic.dates module uses aware and naive datetime objects together, which breaks all date-based views except YearArchiveView.
>
> Let's have, for example:
> - America/Chicago as TIME_ZONE
> - an article, published at 2012-12-31 23:00:00 in local time zone (2012-01-01 05:00:00 UTC)
> - an url /articles/{year}/ which returns list of articles for requested year
> - an url /articles/{year}/{month}/ which returns list of articles for requested month
>
> As I understand, year and month must be in UTC in urls
> or date_list from all date-based generic views is useless, because it contains dates in UTC.
> So, our article must be in /articles/2012/ and in /articles/2012/01/. But it won't be in /articles/2012/01/, because MonthArchiveView will use datetime.date objects, which will be treated as naive datetime.datetime object by ORM, and local time zone will be used.
The behavior you're describing is the expected behavior, it's mostly backwards compatible and in my opinion it's the least unreasonable option.
See also :
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#faq
http://groups.google.com/group/django-developers/browse_thread/thread/cf0423bbb85b1bbf
Best regards,
--
Aymeric.
Mike Yumatov
Apr 28, 2012, 1:56:28 AM4/28/12
to django-d...@googlegroups.com
Hi Aymeric,
On Friday, April 27, 2012 at 9:21 PM, Aymeric Augustin wrote:
> > After some research, I understand that there are more problems with this views, than I thought at first. django.views.generic.dates module uses aware and naive datetime objects together, which breaks all date-based views except YearArchiveView.
> >
> > Let's have, for example:
> > - America/Chicago as TIME_ZONE
> > - an article, published at 2012-12-31 23:00:00 in local time zone (2012-01-01 05:00:00 UTC)
> > - an url /articles/{year}/ which returns list of articles for requested year
> > - an url /articles/{year}/{month}/ which returns list of articles for requested month
> >
> > As I understand, year and month must be in UTC in urls
>
> They are in local time in the default time zone.
Are you sure? Because if so, YearArchiveView is broken: it uses year lookup (https://docs.djangoproject.com/en/1.4/ref/models/querysets/#year), which is performed in UTC.
Also, date_list context variable from all this views becomes useless, because in contains datetime.datetime objects in UTC. You can't use date_list to build urls in templates in this case. E.g. we have two articles: the first is published at 2012-04-27 in local time zone and at 2012-04-28 in UTC, and the second is published at 2012-04-28 in local time zone and at 2012-04-28 in UTC. date_list from MonthArchiveView will contain only one date - 2012-04-28 in UTC. Depending on what time zone we will use in template to build urls to DayArchiveView (local time zone or UTC), first or second article will not be present in output of this view.
And also, URLs to date-based views become dependent on current time zone (which can be changed for request on some projects), so you can't share this URLs with others and be sure, that they will work for others.
--
Mike Yumatov
On Friday, April 27, 2012 at 9:21 PM, Aymeric Augustin wrote:
> > After some research, I understand that there are more problems with this views, than I thought at first. django.views.generic.dates module uses aware and naive datetime objects together, which breaks all date-based views except YearArchiveView.
> >
> > Let's have, for example:
> > - America/Chicago as TIME_ZONE
> > - an article, published at 2012-12-31 23:00:00 in local time zone (2012-01-01 05:00:00 UTC)
> > - an url /articles/{year}/ which returns list of articles for requested year
> > - an url /articles/{year}/{month}/ which returns list of articles for requested month
> >
> > As I understand, year and month must be in UTC in urls
>
> They are in local time in the default time zone.
Also, date_list context variable from all this views becomes useless, because in contains datetime.datetime objects in UTC. You can't use date_list to build urls in templates in this case. E.g. we have two articles: the first is published at 2012-04-27 in local time zone and at 2012-04-28 in UTC, and the second is published at 2012-04-28 in local time zone and at 2012-04-28 in UTC. date_list from MonthArchiveView will contain only one date - 2012-04-28 in UTC. Depending on what time zone we will use in template to build urls to DayArchiveView (local time zone or UTC), first or second article will not be present in output of this view.
And also, URLs to date-based views become dependent on current time zone (which can be changed for request on some projects), so you can't share this URLs with others and be sure, that they will work for others.
--
Mike Yumatov
Aymeric Augustin
Apr 28, 2012, 2:40:26 AM4/28/12
to django-d...@googlegroups.com
On 28 avr. 2012, at 07:56, Mike Yumatov wrote:
>> They are in local time in the default time zone.
> Are you sure? Because if so, YearArchiveView is broken: it uses year lookup (https://docs.djangoproject.com/en/1.4/ref/models/querysets/#year), which is performed in UTC.
Indeed, you're right, sorry.
>> They are in local time in the default time zone.
> Are you sure? Because if so, YearArchiveView is broken: it uses year lookup (https://docs.djangoproject.com/en/1.4/ref/models/querysets/#year), which is performed in UTC.
In fact a very similar problem was already fixed in the admin following #17830 [1].
I've reopened #18217 [2] for filtering ranges properly. In the current state the list of years, months, days in date_list may still be slightly off. That's in the realm of #17260 [3].
Best regards,
--
Aymeric.
[1] https://code.djangoproject.com/ticket/17830
[2] https://code.djangoproject.com/ticket/18217
[3] https://code.djangoproject.com/ticket/17260
Reply all
Reply to author
Forward
0 new messages