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. > On 3 Oct 2018, at 23:04, Paul Tiplady <p...@qwil.com> wrote: > > 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 > > <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) > > -- > 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-developers+unsubscr...@googlegroups.com > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto:django-developers@googlegroups.com>. > Visit this group at https://groups.google.com/group/django-developers > <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 > > <https://groups.google.com/d/msgid/django-developers/79896a0e-1338-4267-89bd-9904fca4f0d2%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/AB635EB3-EF1B-4145-B7B6-1BAB347EB0FD%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
