#18794: When timezone support is enabled, permalinks for DateDetailView are
impossible.
-------------------------------+--------------------------------------
Reporter: void | Owner: aaugustin
Type: Bug | Status: closed
Component: Generic views | Version: master
Severity: Normal | Resolution: wontfix
Keywords: timezone, tz | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Changes (by aaugustin):
* status: new => closed
* resolution: => wontfix
Comment:
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.
[https://docs.djangoproject.com/en/dev/ref/class-based-views/mixins-date-
based/#datemixin 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 `DateTimeField`s 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/18794#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
