Opened 23 months ago

Last modified 16 months ago

#29822 assigned New feature

Timezone-aware widget for admin site

Reported by: Paul Tiplady Owned by: Martin Angelov
Component: contrib.admin Version: 2.1
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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).

Change History (4)

comment:1 Changed 23 months ago by Tim Graham

Triage Stage: UnreviewedSomeday/Maybe

It would be better to make your proposal on the DevelopersMailingList where it'll reach a wider audience.

comment:2 Changed 23 months ago 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? 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.

comment:3 Changed 23 months ago by Tim Graham

Triage Stage: Someday/MaybeAccepted

django-developers discussion. A reply from Aymeric suggests this might be feasible.

comment:4 Changed 16 months ago by Martin Angelov

Owner: changed from nobody to Martin Angelov
Status: newassigned
Note: See TracTickets for help on using tickets.
Back to Top