Google Groups

Re: Problems with date-based generic views when USE_TZ=True

Mike Yumatov Apr 27, 2012 10:56 PM
Posted in group: Django developers (Contributions to Django itself)
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 (, 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