Callable default on DateField + custom date format = widget._has_changed always true, forms fail to validate
|Reported by:||camillo||Owned by:||nobody|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||yes||Patch needs improvement:||no|
Description (last modified by )
I have a
ModelFormset with some extra forms. The model the forms are based on contains a
default=datetime.date.today, and other fields which are required. It must be possible to submit the formset without filling in all extra forms (which wouldn't validate when empty, due to the fact that there are required fields), so the formset sets
empty_permitted on the extra forms: this lets those forms skip validation as long as their fields have not changed (
if self.empty_permitted and not self.has_changed()) in
BaseForm.full_clean. So far this is all standard formset behaviour.
I need to render the dates in a custom (ie local) format, so I have an
__init__ method on my modelform which replaces the widgets of
DateFields with a
DateInput created with the desired format. This is also rather standard widget customization.
However, this causes Django to incorrectly treat every instance of the form as changed. The problem stems from the fact that Django compares the current data and the initial data in string form. Since the model
DateField has a callable default, it generates a form field with
show_hidden_initial set to True; this causes the form to store the initial value in a separate hidden widget, created by calling hidden_widget on the field. This corresponds to the
HiddenInput class for most formfields, including
HiddenInput renders, it formats the date using the default ISO format instead of the custom format used by the corresponding
DateInput._has_changed sees two different strings (eg 2010-02-13 vs 13/02/2010), and thinks the field has changed even when it has not. In some cases, it may also think it has not changed when it has: for example, when one format is D/M/Y and the other is M/D/Y, and the user happens to change the date from Feb. 1 to Jan. 2 (01/02/2010 vs 01/02/2010).
The patch fixes this problem by having
DateInput._has_changed attempt to parse the initial value using the same format used by the
HiddenInput. If the initial value was a string, and was in that format, then it is converted to a date object, which is later converted back into a string using the
DateInput's own format; otherwise, everything remains as before.