When timezone support is enabled, permalinks for DateDetailView are impossible.

[Alexey Boriskin]

With timezone support enabled, permalinks for DateDetailView are hard to create.

As clearly stated in docstring of DateMixin._make_date_lookup_arg,

        When time zone support is enabled, `date` is assumed to be in the
        current time zone, so that displayed items are consistent with the URL.

As current time zone is a time zone of the current user, web site should generate different urls for different users in order them view same content and not 404 page. That's weird: we don't have permalinks anymore. User in Moscow may send a link to DateDetailView to another user in New York, and that user will see 404 page. Or it may be DayArchiveView, and user in New York will see another set of records.

I may be not understanding something, as last test in regressiontests.generic_views.dates even checks for this 404. But what is the way I should generate worldwide accessible permalinks?

[Preston Timmons]

If I'm not mistaken, the current timezone means the active TIME_ZONE setting and not the user's timezone.

The test you mentioned saves objects with a UTC timezone, but the queries run are relative to the TIME_ZONE setting--set to "Africa/Nairobi" (UTC+3:00) in this case.

After reviewing this, I can't see anywhere where the url would display different results for users worldwide.

[Alexey Boriskin]

Failing test

[Alexey Boriskin]

Ok, maybe I erroneosly blamed last test. But consider the attached failing test.

[ashleyjsands]

I think you have misunderstood the DateMixin docstring.

Like what Preston said, It doesn't matter what the user's timezone is, but rather what the system's timezone is. Different user's from around the world accessing the same URL should access the same resource. All URLs are independent from the the user's timezone.

I have spoken to Russell M at PyCon AU about this and he agrees. You should open a discussion on the Django Dev mail list if you want to talk about it further.

[Aymeric Augustin]

My first impression was that the OP is right, but this is an expected behavior.

I'd like to double check this before closing the ticket. Thanks.

[Aymeric Augustin]

I can now confirm that the behavior described by the reporter was introduced on purpose in 78ba9670af.

Basically, this is an ill-defined problem: convert between dates and datetimes in a time zone aware world.

​As documented here, the best solution is to back your date-based CBV on a DateField and not on a DateTimeField. Alternatively you could override get_object.

---

Assuming there is a per-user timezone selection mechanism that sets the current time zone, and that the date-based CBV are backed on a DateTimeField -- otherwise none of these problems occur -- there are two possible default implementations for the date-based CBV (I say "default" because the point of CBVs is to let you override the bits you want):

• use the default time zone (settings.TIME_ZONE)
  • the same items will always be displayed at the same URL, and the DateDetailView URLs will be permalinks
  • the date of the items, as displayed to the end user, may not match the URL
• use the current time zone (the end user's time zone) -- this is what Django currently does
  • the same URL may display different items
  • the date of the items will always match the URL

Both solutions are bound to annoy a subset of Django users. I've chosen the second one because I've heard "this page displays items for yesterday / tomorrow!" more often "the URL changes depending on the user!". Also, Django consistently works in the default time zone in the model layer and in the current time zone in the view / template layer. That said, to be honest, the CBVs span these layers, and I hesitated a lot before deciding to use the current time zone.

Finally, when implementing this, I also considered forbidding date-based CBVs backed on DateTimeFields when USE_TZ = True. But they work perfectly when the current time zone isn't set per-user and stays identical to the default time zone, so I preferred to leave them available and add a warning in the docs.

---

If you think my decisions in this area are incorrect -- which is totally possible as I got very little feedback during the implementation of these parts -- please start a discussion on the django-developers mailing-list.

For now I will mark this "wontfix" because you're seeing a known behavior.