[Django] #29822: Timezone-aware widget for admin site
Django
-----------------------------------------+------------------------
Reporter: Paul Tiplady | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 2.1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
Timezone handling in the Django admin is quite confusing for users when
the users are in multiple timezones, because everything in the admin site
operates in the server's time.
Assuming USE_TZ=True, TIME_ZONE='UTC', USE_I18N, USE_L10N, when viewing a
datetime field, users see the UTC time, with a note below saying "Note:
You are 7 hours behind server time". This is better than nothing, but with
a modern browser I believe it's possible to improve the situation.
The ideal behaviour (I believe) would be localizing the timezones in the
browser to the user's own time zone, and submitting back to the app using
TZ-aware timestamp strings. It's possible to pull the TZ unambiguously
from a modern browser: https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/resolvedOptions#Browser_compatibility#Description.
`Intl.DateTimeFormat().resolvedOptions().timeZone`
Would this approach be acceptable? It seems that we'd want to default to
the normal behaviour, and perhaps have this as config on the AdminSite
object (since we want a way to enable this globally for sites that wish to
use this feature).
--
Ticket URL: <https://code.djangoproject.com/ticket/29822>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Paul Tiplady | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 2.1
Keywords: | Triage Stage: Someday/Maybe
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* stage: Unreviewed => Someday/Maybe
Comment:
It would be better to make your proposal on the DevelopersMailingList
where it'll reach a wider audience.
--
Ticket URL: <https://code.djangoproject.com/ticket/29822#comment:1>
Django
Reporter: Paul Tiplady | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 2.1
Keywords: | Triage Stage: Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Simon Charette):
> ... because everything in the admin site operates in the server's time.
Not exactly true, everything operates in
`django.utils.timezone.get_current_timezone()` which defaults to
`settings.TIME_ZONE` unless you've defined a middleware that overrides it.
> The ideal behaviour (I believe) would be localizing the timezones in the
browser to the user's own time zone, and submitting back to the app using
TZ-aware timestamp strings.
That's the pattern we use for translations based off the `Accept-Language`
header.
> t's possible to pull the TZ unambiguously from a modern browser:
https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/resolvedOptions#Browser_compatibility#Description.
The main issue I see here is that we'd have to figure out a way to send
this data to the server. Maybe at admin login?
[https://github.com/charettes/django-sundial Another pattern is to allow
users to define their own timezone through the admin using a field defined
on their user model] or to base it off geoip.
As Tim said this should be discussed on developer mailing list from now on
but I believe Django should definitively make a better job at providing
batteries to deal with timezone localization.
--
Ticket URL: <https://code.djangoproject.com/ticket/29822#comment:2>
Django
Reporter: Paul Tiplady | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 2.1
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* stage: Someday/Maybe => Accepted
Comment:
[https://groups.google.com/d/topic/django-
developers/ti1wh0S_gLc/discussion django-developers discussion]. A reply
from Aymeric suggests this might be feasible.
--
Ticket URL: <https://code.djangoproject.com/ticket/29822#comment:3>
Django
Reporter: Paul Tiplady | Owner: martin056
Type: New feature | Status: assigned
Component: contrib.admin | Version: 2.1
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by martin056):
* owner: nobody => martin056
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/29822#comment:4>
Django
Reporter: Paul Tiplady | Owner: Shubh Parmar
Type: New feature | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Shubh Parmar):
* owner: Martin Angelov => Shubh Parmar
--
Ticket URL: <https://code.djangoproject.com/ticket/29822#comment:5>
Django
Reporter: Paul Tiplady | Owner: Shubh Parmar
Type: New feature | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Shubh Parmar):
PR [https://github.com/django/django/pull/15155]
--
Ticket URL: <https://code.djangoproject.com/ticket/29822#comment:6>
Django
Reporter: Paul Tiplady | Owner: Shubh Parmar
Type: New feature | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Jacob Walls):
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29822#comment:7>
Django
Reporter: Paul Tiplady | Owner: Shubh Parmar
Type: New feature | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Shubh Parmar):
Do I have to do anything else in this PR?
--
Ticket URL: <https://code.djangoproject.com/ticket/29822#comment:8>
Django
Reporter: Paul Tiplady | Owner: Shubh Parmar
Type: New feature | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* needs_better_patch: 0 => 1
* needs_tests: 0 => 1
* needs_docs: 0 => 1
Comment:
[https://github.com/django/django/pull/15155#pullrequestreview-911365399
Comments on PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/29822#comment:9>
Django
Reporter: Paul Tiplady | Owner: Shubh Parmar
Type: New feature | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Comment (by Denny Biasiolli):
What about using standard input types and use `isoformat()` strings in
templates?
- input type="date"
https://caniuse.com/mdn-html_elements_input_type_date
- input type="time"
https://caniuse.com/mdn-html_elements_input_type_time
- input type="datetime-local"
https://caniuse.com/mdn-html_elements_input_type_datetime-local
I can help with that
--
Ticket URL: <https://code.djangoproject.com/ticket/29822#comment:10>