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.
* 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.
* Attachment "chrome-console-error.png" added.
Error in chrome dev console.
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>
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>
* 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>