Code

#18794 closed Bug (wontfix)

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

Reported by: void Owned by: aaugustin
Component: Generic views Version: master
Severity: Normal Keywords: timezone, tz
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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?

Attachments (1)

failing_test.txt (1.0 KB) - added by void 23 months ago.
Failing test

Download all attachments as: .zip

Change History (7)

comment:1 Changed 23 months ago by prestontimmons

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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.

Changed 23 months ago by void

Failing test

comment:2 Changed 23 months ago by void

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

comment:3 Changed 23 months ago by ashleyjsands

  • Resolution set to invalid
  • Status changed from new to closed

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.

comment:4 Changed 23 months ago by aaugustin

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

comment:5 Changed 23 months ago by aaugustin

  • Owner changed from nobody to aaugustin
  • Status changed from reopened to new

comment:6 Changed 23 months ago by aaugustin

  • Resolution set to wontfix
  • Status changed from new to closed

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.