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.
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.
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.
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].
