[Django] #35255: Inconsistent Behavior of SelectDateWidget._parse_date_fmt()

[Django]

#35255: Inconsistent Behavior of SelectDateWidget._parse_date_fmt()
-------------------------------------+-------------------------------------
Reporter: Peter- | Owner: nobody
Gehlert |
Type: Bug | Status: new
Component: Forms | Version: 5.0
Severity: Normal | Keywords: SelectDateWidget
Triage Stage: | Localization DATE_FORMAT
Unreviewed | Has patch: 1
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
-------------------------------------+-------------------------------------
When looking to change the format of the date in the SelectDateWidget from
the default of Month, Day, Year to Day, Month, Year; all advice i found
pointed to changing the DATE_FORMAT in settings.py however I discovered an
error with the implementation in the widget that prevents this from
changing the format as expected.

When generating the context["widget"]["subwidgets"] in the
SelectDateWidget.get_context() method, the implementation relies on the
SelectDateWidget._parse_date_fmt() static method to determine the date
format.

@staticmethod
def _parse_date_fmt():
fmt = get_format("DATE_FORMAT")

The current implementation of _parse_date_fmt() disregards the lang and
use_l10n parameters, leading to inconsistencies in date formatting.
Specifically, the use_l10n parameter is always set to True by default
within the get_format() function:

if use_l10n is None:
use_l10n = True
if use_l10n and lang is None:
lang = get_language()

This results in the function always returning the default date format as
specified by the LANGUAGE_CODE setting or the language determined by
USE_I18N regardless of any language or localization preferences specified
elsewhere.

Expected Behavior:
The _parse_date_fmt() method should take into account the lang and
use_l10n parameters to allow for language-specific and localization-aware
date formatting. This would ensure that the generated date format respects
the desired language and localization settings.

Recommendation:
Modify the _parse_date_fmt() method to properly handle the lang and
use_l10n parameters when retrieving the date format. This can be achieved
by passing these parameters to the get_format() function within the
method.


@staticmethod
def _parse_date_fmt(lang=None, use_l10n=None):
fmt = get_format(
"DATE_FORMAT",
lang=translation.get_language(),
use_l10n=getattr(django.conf.settings, 'USE_L10N')
)
--
Ticket URL: <https://code.djangoproject.com/ticket/35255>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#35255: Inconsistent Behavior of SelectDateWidget._parse_date_fmt()
-------------------------------------+-------------------------------------

Reporter: Peter-Gehlert | Owner: nobody

Type: Bug | Status: new
Component: Forms | Version: 5.0

Severity: Normal | Resolution:

Keywords: SelectDateWidget | Triage Stage:
Localization DATE_FORMAT | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------

Description changed by David Sanders:

Old description:

New description:

--
Ticket URL: <https://code.djangoproject.com/ticket/35255#comment:1>

[Django]

#35255: Inconsistent Behavior of SelectDateWidget._parse_date_fmt()
-------------------------------------+-------------------------------------
Reporter: Peter-Gehlert | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 5.0
Severity: Normal | Resolution:
Keywords: SelectDateWidget | Triage Stage:
Localization DATE_FORMAT | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by David Sanders):

Have you tried setting the `DATE_FORMAT` in your custom language format
file as per: https://docs.djangoproject.com/en/5.0/topics/i18n/formatting
/#creating-custom-format-files ?
--
Ticket URL: <https://code.djangoproject.com/ticket/35255#comment:2>

[Django]

#35255: Inconsistent Behavior of SelectDateWidget._parse_date_fmt()
-------------------------------------+-------------------------------------
Reporter: Peter-Gehlert | Owner:

| sagarsadhu
Type: Bug | Status: assigned

Component: Forms | Version: 5.0
Severity: Normal | Resolution:
Keywords: SelectDateWidget | Triage Stage:
Localization DATE_FORMAT | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by sagarsadhu):

* owner: nobody => sagarsadhu
* status: new => assigned

--
Ticket URL: <https://code.djangoproject.com/ticket/35255#comment:3>

[Django]

#35255: Inconsistent Behavior of SelectDateWidget._parse_date_fmt()
-------------------------------------+-------------------------------------
Reporter: Peter-Gehlert | Owner:
| sagarsadhu
Type: Bug | Status: assigned
Component: Forms | Version: 5.0
Severity: Normal | Resolution:

Keywords: SelectDateWidget | Triage Stage: Accepted
Localization DATE_FORMAT |

Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by sagarsadhu):

* stage: Unreviewed => Accepted

--
Ticket URL: <https://code.djangoproject.com/ticket/35255#comment:4>

[Django]

#35255: Inconsistent Behavior of SelectDateWidget._parse_date_fmt()
-------------------------------------+-------------------------------------

Reporter: Peter-Gehlert | Owner: Sagar
| Sadhu
Type: Bug | Status: closed
Component: Forms | Version: 5.0
Severity: Normal | Resolution: invalid

Keywords: SelectDateWidget | Triage Stage:
Localization DATE_FORMAT | Unreviewed

Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by David Sanders):

* resolution: => invalid
* stage: Accepted => Unreviewed
* status: assigned => closed

Comment:

Resolving as invalid assuming there was a misunderstanding on how the new
localisation settings work in Django 5.0. If this is a feature request
please head over to the Django forum to discuss proposal to make changes
👍 https://www.djangoproject.com/community/
--
Ticket URL: <https://code.djangoproject.com/ticket/35255#comment:5>