Hello @dennybiasiolli! Thank you for your contribution 💪

As it’s your first contribution be sure to check out the patch review checklist.

If you’re fixing a ticket from Trac make sure to set the “Has patch” flag and include a link to this PR in the ticket!

If you have any design or process questions then you can ask in the Django forum.

Welcome aboard ⛵️!

What are the consequences if the admin is for instance set to german and my browser is set to english? I think it would be great to add a table here to show the current behavior and the new behaviors and possible issues.

have you thought at all about an opt-in or opt-out, and a migration/deprecation path?

Oh you are right, I didn’t think about that.
What do you think is better?

• a new option passed in models.DateTimeField, models.DateField and models.TimeField?
• new classes in forms/fields.py
• something else?

What are the consequences if the admin is for instance set to german and my browser is set to english? I think it would be great to add a table here to show the current behavior and the new behaviors and possible issues.

In this case, you will se the the HTML input in the browser’s language, but the date/datetime used to pass data to the python code is the same il all cases, the ISO8601 format: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date

Ok, let me push another commit (basically rolling back almost everything) adding opt-in admin widgets.
Added as new commit, will rebase/squash/nicely-commit as soon as I know how to proceed.

They can be configured in ModelAdmin classes like this

from django.contrib import admin
from django.contrib.admin import widgets
from django.db import models

@admin.register(MyCustom)
class MyCustomAdmin(admin.ModelAdmin):
    formfield_overrides = {
        models.DateField: { 'widget': widgets.AdminDateISOWidget },
        models.TimeField: { 'widget': widgets.AdminTimeISOWidget },
        models.DateTimeField: {
            'widget': widgets.AdminDateTimeISOWidget,
            'form_class': None,
        },
    }

Thanks @dennybiasiolli. That sounds a good plan.

I will have a proper look next week and we’ll see about the best way forwards!

@carltongibson thanks! Meanwhile I will add a few more tests for the code I added

Should these widgets be enabled by default? I think that everyone would appreciate seeing time fields converted to local time on their browser.

Plus: If a datetime field has editable=False, the django admin doesn’t display the “You are x hours behind/ahead of server time”, which is confusing and a bit ugly. If you enable this widget by default, it would solve that issue too.

@ldeluigi at the moment the widget is “just” using the standard html input types for date and times, not the local time.
I think for that we need another PR involving the display of DateTime fields in the admin list/change/etc…
For this reason the message “You are x hours behind/ahead of server time” is displayed

@ldeluigi at the moment the widget is “just” using the standard html input types for date and times, not the local time. I think for that we need another PR involving the display of DateTime fields in the admin list/change/etc… For this reason the message “You are x hours behind/ahead of server time” is displayed

Should it be implemented with a new middleware that calls activate() using a session/cookie/HTTP header set by javascript, maybe at login?

Or should it be javascript only, that shifts times, dates and datetimes before the user sees them, to local timezone?

I don’t feel capable of such contribution given my lack of experience with Django

@ldeluigi I think it can be something “javascript only”, so when in a template we have something with a specific class, or with a specific data- attribute, we can change it from an ISO format to the user’s localization/timezone.
For example, if there is a

<span class="date-time" data-iso-format="2022-07-27T07:37:53.005Z">

We can do something like this (note: pseudo-code)

const elems = document.getElementsByClassName('date-time');
for (let elem of elems) {
  if (elem.dataset.isoFormat) {
    elem.innerHTML = new Intl.DateTimeFormat().format(new Date());  // need to adjust this with options for date, time and datetime
  }
}

Hi @dennybiasiolli, would you have time to keep working on this? Thank you!

Yep, give me a couple of days and I will rebase and work on this

Just flagging that from my perspective on Django’s accessibility team, I can’t recommend anyone use those input types. As much as I’d like to see projects adopting the native inputs, my understanding is that they’re close to completely unusable with the Dragon voice recognition software, which is by far the most popular speech recognition software in the world. For ref, see:

• (video demo) CSUN ATC 17: Dragon and the HTML5 date input type
• input[type="date"] compatibility matrix on a11ysupport
• Results of the 2016 GOV.UK assistive technology survey

Those references are from 2019, 2021, and 2016 – so my preference if we wanted to proceed with this in Django would be to get help from a user of Dragon in our community, and have them report back with a recording + qualitative assessment of their experience going through the different widgets with the latest version of Dragon. Alternatively this is something @django/accessibility might be able to do if we got budget to pay for a Dragon license ($700). We’d then be able to make an informed decision on whether those input types are ready for use or not.

See also similar research from other projects:

• GOV.UK – dates issue (and related issues)
• Wagtail – Replace date & date time picker widget with native browser date pickers

Ok, branch rebased, I will wait for further decisions before working on this 😉

Ok, branch rebased, I will wait for further decisions before working on this 😉

Thanks! Would you be willing to chase the accessibility aspect of this? I have started by prompting for help in the #accessibility Discord channel:

https://discord.com/channels/856567261900832808/931568482489860137/1157367597185106062

It would be of great help if you could find someone to help you test the UI/UX aspect of this.

I’m a Dragon user and a programmer who uses django, hit me up if you need me.

Thank you @deborahgu! I’ll put together a prototype and then you can try it out, tell us about your experience and provide a recording if it works for you?

sounds great!

I’m a Dragon user and a programmer who uses django, hit me up if you need me.

Hi @deborahgu ! Are you still open to give this a test run?

I’m a Dragon user and a programmer who uses django, hit me up if you need me.

Hi @deborahgu ! Are you still open to give this a test run?

hey, sorry, got behind on my email. I am open to it if you still need someone!

yes please @deborahgu !

Hi @deborahgu ! Are you still open to give this a test run?
hey, sorry, got behind on my email. I am open to it if you still need someone!

Hi @deborahgu! That would be great! Thanks for your offer!

I setup a Django instance with the changes from this PR at https://native.e11bits.com . I shared a private repository on github with you that contains a link to the credentials (expires after 7 days).

I will provide more information in the repository I shared with you.

Anything I can do to help this issue? I know there has been concerned about peoples code being broken by implementing it, but there are also people with forms that have already been broken by Django 4->5 by not having this, and are looking for a fix.

Just for reference i would like to point to https://github.com/adamcharnock/django-tz-detect

This app will auto-detect a user’s timezone using JavaScript, then configure Django’s timezone localization system accordingly. As a result, dates shown to users will be in their local timezones.