Context Navigation

← Previous Ticket
Next Ticket →

#29822 assigned New feature

Timezone-aware widget for admin site

Reported by:	Paul Tiplady	Owned by:	Shubh Parmar
Component:	contrib.admin	Version:	2.1
Severity:	Normal	Keywords:
Cc:		Triage Stage:	Accepted
Has patch:	yes	Needs documentation:	yes
Needs tests:	yes	Patch needs improvement:	yes
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 (10)

comment:1 by Tim Graham, 6 years ago

Triage Stage:	Unreviewed → Someday/Maybe

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

comment:2 by Simon Charette, 6 years ago

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