Proposal: local timezone-aware datetime fields in the admin site

[Paul Tiplady]

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

(Originally raised here: https://code.djangoproject.com/ticket/29822, posting for discussion)

[Aymeric Augustin]

Hello Paul,

Yes, if that works, it would be great.

The API you're pointing to returns a timezone name. This is better than an offset because it avoids being off by one hour when editing dates or times on the other side of the DST change.

You need to check what it does on Windows (which, I'm afraid, has its own time zone name) and whether it's locale-dependent (that would be a mess).

If this API reliably returns a timezone name that pytz understands, then you should be able to achieve your goal in the Widget for datetime fields and to preserve backwards-compatibility.

Best regards,

-- 

Aymeric.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/79896a0e-1338-4267-89bd-9904fca4f0d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Tiplady]

Thanks Aymeric,

A bit of digging gives:

MacOS Chrome: "America/Los_Angeles"

MacOS Firefox: "America/Los_Angeles"

MacOS Safari: "America/Los_Angeles"

Windows Edge: ""America/Los_Angeles"

Do you know what OS/browser combination you were referring to with "Windows (which, I'm afraid, has its own time zone name)"?

I haven't got around to testing locales, I'll report back once I do that.

[Aymeric Augustin]

Hello,

Do you know what OS/browser combination you were referring to with "Windows (which, I'm afraid, has its own time zone name)"?

At the system level, I'm not sure Windows is using (or was using) the timezone database (formerly known as the Olson database). I remember this being an issue but I have forgotten the details. (Most of my work in this area of Django was 7 years ago.)

Your tests show that browsers normalize to the same timezone names, including Edge on Windows, which is good news. Furthermore the spec says: [[timeZone]] is a String value with the IANA time zone name of the time zone used for formatting.

We can rely on this API. There's not need to test with another locale. Sorry for the noise!

Best regards,

-- 

Aymeric.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b668a840-4884-4dc7-908f-32e2a2b493b9%40googlegroups.com.