[Django] #31595: models.Datefield being localized where it shouldn't

2 views
Skip to first unread message

Django

unread,
May 16, 2020, 4:03:46 AM5/16/20
to django-...@googlegroups.com
#31595: models.Datefield being localized where it shouldn't
-------------------------------------+-------------------------------------
Reporter: | Owner: nobody
akshaysalunke13 |
Type: Bug | Status: new
Component: | Version: 2.2
Internationalization | Keywords: DateField, chrome,
Severity: Normal | date, format
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
So, I have a DateField in my model and have also set I18N & L10N to `True`
in settings. When a browser running `en-AU` locale visits the website,
Django tries to parse the value read from model, using the first value in
`DATE_INPUT_FORMATS` from /conf.

The bug is when a user in `en-AU` locale visits the website, Django reads
the Datefield value from model and tries to localize it for `en-AU` locale
(from `DATE_INPUT_FORMATS` in /conf/en_AU) to this format `'%d/%m/%Y'`,
but html5 requires the `value` for `<input type="date">` to be explicitly
in this format: yyyy-MM-dd. [ref](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/input/date) [ref2](https://developer.mozilla.org
/en-US/docs/Web/HTML/Date_and_time_formats#Format_of_a_valid_date_string).

This causes an error in chrome dev console and the HTML date field
rendered without the date read from the model.[[Image(https://user-
images.githubusercontent.com/2255284/82113682-326dc080-979b-11ea-8e7f-
c442f30aae1f.png)]]
[[Image(https://user-
images.githubusercontent.com/2255284/82113676-2255e100-979b-11ea-973b-
564fdb4a3497.png)]]

**This bug goes away when I disable L10N in settings. I am able to
reproduce this bug in `en-AU` and `en-GB`**

--
Ticket URL: <https://code.djangoproject.com/ticket/31595>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
May 16, 2020, 4:05:17 AM5/16/20
to django-...@googlegroups.com
#31595: models.Datefield being localized where it shouldn't
-------------------------------------+-------------------------------------
Reporter: akshaysalunke13 | Owner: nobody

Type: Bug | Status: new
Component: | Version: 2.2
Internationalization |
Severity: Normal | Resolution:
Keywords: DateField, chrome, | Triage Stage:
date, format | Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by akshaysalunke13):

* Attachment "datepicker-chrome.png" added.

This is how date picker looks in chrome when locale is en-AU even when
this field has an initials value.

Django

unread,
May 16, 2020, 4:05:47 AM5/16/20
to django-...@googlegroups.com
#31595: models.Datefield being localized where it shouldn't
-------------------------------------+-------------------------------------
Reporter: akshaysalunke13 | Owner: nobody

Type: Bug | Status: new
Component: | Version: 2.2
Internationalization |
Severity: Normal | Resolution:
Keywords: DateField, chrome, | Triage Stage:
date, format | Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by akshaysalunke13):

* Attachment "chrome-console-error.png" added.

Error in chrome dev console.

Django

unread,
May 16, 2020, 4:07:33 AM5/16/20
to django-...@googlegroups.com
#31595: models.Datefield being localized where it shouldn't
-------------------------------------+-------------------------------------
Reporter: akshaysalunke13 | Owner: nobody

Type: Bug | Status: new
Component: | Version: 2.2
Internationalization |
Severity: Normal | Resolution:
Keywords: DateField, chrome, | Triage Stage:
date, format | Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by akshaysalunke13:

Old description:

> So, I have a DateField in my model and have also set I18N & L10N to
> `True` in settings. When a browser running `en-AU` locale visits the
> website, Django tries to parse the value read from model, using the first
> value in `DATE_INPUT_FORMATS` from /conf.
>
> The bug is when a user in `en-AU` locale visits the website, Django reads
> the Datefield value from model and tries to localize it for `en-AU`
> locale (from `DATE_INPUT_FORMATS` in /conf/en_AU) to this format
> `'%d/%m/%Y'`, but html5 requires the `value` for `<input type="date">` to
> be explicitly in this format: yyyy-MM-dd.
> [ref](https://developer.mozilla.org/en-
> US/docs/Web/HTML/Element/input/date) [ref2](https://developer.mozilla.org
> /en-
> US/docs/Web/HTML/Date_and_time_formats#Format_of_a_valid_date_string).
>
> This causes an error in chrome dev console and the HTML date field
> rendered without the date read from the model.[[Image(https://user-
> images.githubusercontent.com/2255284/82113682-326dc080-979b-11ea-8e7f-
> c442f30aae1f.png)]]
> [[Image(https://user-
> images.githubusercontent.com/2255284/82113676-2255e100-979b-11ea-973b-
> 564fdb4a3497.png)]]
>
> **This bug goes away when I disable L10N in settings. I am able to
> reproduce this bug in `en-AU` and `en-GB`**

New description:

So, I have a DateField in my model and have also set **I18N & L10N** to


`True` in settings. When a browser running `en-AU` locale visits the
website, Django tries to parse the value read from model, using the first
value in `DATE_INPUT_FORMATS` from /conf.

The bug is when a user in `en-AU` locale visits the website, Django reads
the Datefield value from model and tries to localize it for `en-AU` locale
(from `DATE_INPUT_FORMATS` in /conf/en_AU) to this format `'%d/%m/%Y'`,
but html5 requires the `value` for `<input type="date">` to be explicitly
in this format: yyyy-MM-dd. [ref](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/input/date) [ref2](https://developer.mozilla.org
/en-US/docs/Web/HTML/Date_and_time_formats#Format_of_a_valid_date_string).

This causes an error in chrome dev console and the HTML date field
rendered without the date read from the model.[[Image(https://user-
images.githubusercontent.com/2255284/82113682-326dc080-979b-11ea-8e7f-
c442f30aae1f.png)]]
[[Image(https://user-
images.githubusercontent.com/2255284/82113676-2255e100-979b-11ea-973b-
564fdb4a3497.png)]]

**This bug goes away when I disable L10N in settings. I am able to
reproduce this bug in `en-AU` and `en-GB`**

--

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

Django

unread,
May 16, 2020, 4:10:39 AM5/16/20
to django-...@googlegroups.com
#31595: models.Datefield being localized where it shouldn't
-------------------------------------+-------------------------------------
Reporter: akshaysalunke13 | Owner: nobody

Type: Bug | Status: new
Component: | Version: 2.2
Internationalization |
Severity: Normal | Resolution:
Keywords: DateField, chrome, | Triage Stage:
date, format | Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Old description:

> So, I have a DateField in my model and have also set **I18N & L10N** to


> `True` in settings. When a browser running `en-AU` locale visits the
> website, Django tries to parse the value read from model, using the first
> value in `DATE_INPUT_FORMATS` from /conf.
>
> The bug is when a user in `en-AU` locale visits the website, Django reads
> the Datefield value from model and tries to localize it for `en-AU`
> locale (from `DATE_INPUT_FORMATS` in /conf/en_AU) to this format
> `'%d/%m/%Y'`, but html5 requires the `value` for `<input type="date">` to
> be explicitly in this format: yyyy-MM-dd.
> [ref](https://developer.mozilla.org/en-
> US/docs/Web/HTML/Element/input/date) [ref2](https://developer.mozilla.org
> /en-
> US/docs/Web/HTML/Date_and_time_formats#Format_of_a_valid_date_string).
>
> This causes an error in chrome dev console and the HTML date field
> rendered without the date read from the model.[[Image(https://user-
> images.githubusercontent.com/2255284/82113682-326dc080-979b-11ea-8e7f-
> c442f30aae1f.png)]]
> [[Image(https://user-
> images.githubusercontent.com/2255284/82113676-2255e100-979b-11ea-973b-
> 564fdb4a3497.png)]]
>
> **This bug goes away when I disable L10N in settings. I am able to
> reproduce this bug in `en-AU` and `en-GB`**

New description:

So, I have a DateField in my model and have also set **I18N & L10N** to


`True` in settings. When a browser running `en-AU` locale visits the
website, Django tries to parse the value read from model, using the first
value in `DATE_INPUT_FORMATS` from /conf.

The bug is when a user in `en-AU` locale visits the website, Django reads
the Datefield value from model and tries to localize it for `en-AU` locale
(from `DATE_INPUT_FORMATS` in /conf/en_AU) to this format `'%d/%m/%Y'`,
but html5 requires the `value` for `<input type="date">` to be explicitly

in this format: yyyy-MM-dd. [[https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/input/date| ref1]]
[[https://developer.mozilla.org/en-
US/docs/Web/HTML/Date_and_time_formats#Format_of_a_valid_date_string |
ref2]]

This causes an error in chrome dev console and the HTML date field
rendered without the date read from the model.[[Image(https://user-
images.githubusercontent.com/2255284/82113682-326dc080-979b-11ea-8e7f-
c442f30aae1f.png)]]
[[Image(https://user-
images.githubusercontent.com/2255284/82113676-2255e100-979b-11ea-973b-
564fdb4a3497.png)]]

**This bug goes away when I disable L10N in settings. I am able to
reproduce this bug in `en-AU` and `en-GB`**

--

Comment (by akshaysalunke13):

Replying to [ticket:31595 akshaysalunke13]:
> So, I have a DateField in my model and have also set **I18N & L10N** to


`True` in settings. When a browser running `en-AU` locale visits the
website, Django tries to parse the value read from model, using the first
value in `DATE_INPUT_FORMATS` from /conf.
>
> The bug is when a user in `en-AU` locale visits the website, Django
reads the Datefield value from model and tries to localize it for `en-AU`
locale (from `DATE_INPUT_FORMATS` in /conf/en_AU) to this format
`'%d/%m/%Y'`, but html5 requires the `value` for `<input type="date">` to
be explicitly in this format: yyyy-MM-dd.
[ref](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/input/date) [ref2](https://developer.mozilla.org
/en-US/docs/Web/HTML/Date_and_time_formats#Format_of_a_valid_date_string).
>
> This causes an error in chrome dev console and the HTML date field
rendered without the date read from the model.[[Image(https://user-
images.githubusercontent.com/2255284/82113682-326dc080-979b-11ea-8e7f-
c442f30aae1f.png)]]
> [[Image(https://user-
images.githubusercontent.com/2255284/82113676-2255e100-979b-11ea-973b-
564fdb4a3497.png)]]
>
> **This bug goes away when I disable L10N in settings. I am able to
reproduce this bug in `en-AU` and `en-GB`**

--
Ticket URL: <https://code.djangoproject.com/ticket/31595#comment:2>

Django

unread,
May 16, 2020, 7:55:41 AM5/16/20
to django-...@googlegroups.com
#31595: models.Datefield being localized where it shouldn't
-------------------------------------+-------------------------------------
Reporter: Akshay Salunke | Owner: nobody
Type: Bug | Status: closed
Component: | Version: 2.2
Internationalization |
Severity: Normal | Resolution: invalid

Keywords: DateField, chrome, | Triage Stage:
date, format | Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Claude Paroz):

* status: new => closed
* resolution: => invalid


Comment:

AFAIK Django does not use `type="date"` for its widgets due to browser
support being too variable. If you set it yourself, you should at least
force the form fields initialized with `localize=False`. Anyway, this is
entering support territory.

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

Reply all
Reply to author
Forward
0 new messages