[Admin] Improve the admin's handling of dates and times

[kevinrenskers]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

Add a dropdown to the navigation bar (or somewhere else) with time zones, so that dates and times can be entered for a specific time zone without having to calculate anything.

Problem

Question: when you see this help text under a field in the Django Admin, do you know what it means?

“Note: You are 1 hour ahead of server time.” Uhm, ok? Does that mean I have to enter times with an offset of one hour? Do I add an hour or subtract an hour? Or do I enter times “as is”, and Django is smart enough to deal with the difference of my time zone and “server time”?

My Django project has admins in multiple time zones, and literally all of them have asked me what they are supposed to fill in there. For example, let’s say that we want an item to be active from March 1, 2025 at 8:00, Pacific Time. The staff member in question is located in Berlin. Does this person enter 17:00, which is Pacific Time translated to CET? But you get this warning about being ahead of server time. So does the admin enter 16:00 instead? Or 18:00? What even is the “server time”, and why should this person care? I happen to know it’s set to UTC, but my admins don’t know that!

You know what would make this much better? A dropdown with time zones that goes into the navigation bar (or somewhere else), so that dates and times can be entered for a specific time zone without having to calculate anything. And the Admin can show these values translated to that time zone as well.

Request or proposal

request

Additional Details

See also https://forum.djangoproject.com/t/djangos-handling-of-datetimes-in-the-admin-interface-can-be-greatly-improved/36823 and https://www.loopwerk.io/articles/2025/django-admin-datetime/.

Implementation Suggestions

No response

[github-actions]

Thank you kevinrenskers for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[LilyFirefly]

If we come to a consensus here that changing this is the right thing to do, the next step would be to re-open https://code.djangoproject.com/ticket/35951.

I personally think it's something worth fixing and I think the forum thread points heavily in that direction too.