Fixed #33113 -- Doc'd a forms.DateInput type=date example.

[dennisvang]

This is my first pull request for django, so please let me know if anything could be improved. Thanks.

ticket-33113

[github-actions[bot]]

Hello @dennisvang! 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 ⛵️!

[claudep]

We could maybe refer to discussions on the ticket https://code.djangoproject.com/ticket/16630, or are they too old to be still valid?

[carltongibson]

@claudep — The reason not to use type=date is localisation issues, is that right? Do you have any thoughts for what you'd say here to that effect?

[claudep]

I guess that issues varies from browser to browser. It would be great to get feedback from someone having recently experienced with such use cases (especially if such issues remain). Sorry, I'm a bit short of inspiration right now for a good way of expressing our current choice.

[carltongibson]

@claudep Let me ask on the mailing list. Thanks!

[ngnpope]

I think all browsers support the "date" input type, ...

The reason not to use type=date is localisation issues, is that right?

Yes, we need to explain the reasoning. Otherwise the next person will come along and say, "But don't all browsers support <input type="date">? Why isn't this the default? Let's create a new ticket / pull request to 'fix' it...".

It would be great to get feedback from someone having recently experienced with such use cases (especially if such issues remain).

Indeed, the first thing is to identify whether there is still an issue that blocks us from doing this by default. Maybe something has changed over the past decade...

---

As an aside, surely the localisation issue was also the reason for not including the following:

• datetime-local for DateTimeField. (Interestingly, there was a datetime, but it was deprecated.)
• time for TimeField.

Perhaps the documentation should also be updated for these too while we're at it?

[claudep]

Just a note: If at some point we think that date input types are now safe, we could start by dogfooding in the admin site (before changing the default widget).

[nessita]

I guess that issues varies from browser to browser. It would be great to get feedback from someone having recently experienced with such use cases (especially if such issues remain). Sorry, I'm a bit short of inspiration right now for a good way of expressing our current choice.

An example of a very very recent instance is ticket 34853

The reporter had a couple of date fields (borrowed_from_date and borrowed_to_date) in a model instance, that were rendered in a ModelForm as both localized and with an override to have them being:

    widgets = {
        ...,
        "borrowed_from_date": forms.DateInput(attrs={"type": "date"}),
        "borrowed_to_date": forms.DateInput(attrs={"type": "date"}),
    }

The reporter's site also offered a dropdown to change the preferred language using the set_language view. The main issue here is a disconnect between the language cookie and the browser's locale (sent via the Accept-Language header).

[nessita]

Just a note: If at some point we think that date input types are now safe, we could start by dogfooding in the admin site (before changing the default widget).

I believe this is PR #15806?

[nessita]

@claudep Let me ask on the mailing list. Thanks!

Discussion is https://groups.google.com/g/django-developers/c/wp-pnzcB25o/m/D5gEOzPIAQAJ

[nessita]

@dennisvang Do you have time to keep working on this?

[nessita]

Closing due to inactivity.