id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
22502	Datetime fields break empty form validation on first attempt (but not second)	Stephen Burrows	Stephen Burrows	"It turns out that if you have a form with ```empty_permitted=True``` (for example, an extra form in a formset) and that form has a datetime field defaulting to ```(timezone.)now```, the form will fail validation the first time you save *even if you touch nothing* – but it will succeed if you immediately save again.

The reason for this seems to lie in the way that initial values for datetime fields with defaults are calculated. Specifically, for some reason, on first page load, the hidden ""initial"" field will include microseconds - but the displayed datetime field will not. Example:

{{{
<input class=""form-control"" type=""datetime"" name=""options-3-available_start"" value=""2014-04-24 08:03:22"" required="""" id=""id_options-3-available_start"">
<input type=""hidden"" name=""initial-options-3-available_start"" value=""2014-04-24 08:03:22.688836"" id=""initial-options-3-id_options-3-available_start"">
}}}

This means that the field (and thus the form) is marked as ""changed"". However, when the page is re-rendered (with validation errors) the initial field's microseconds vanish. Example:

{{{
<input class=""form-control"" type=""datetime"" name=""options-1-available_start"" value=""2014-04-24 08:03:22"" required="""" id=""id_options-1-available_start"">
<input type=""hidden"" name=""initial-options-1-available_start"" value=""2014-04-24 08:03:22"" id=""initial-options-1-id_options-1-available_start"">
}}}

So the form validates just fine on the second go-round.

I'm technically using the latest code on the 1.7.X branch, not 1.7-beta-2."	Bug	closed	Forms	dev	Normal	fixed		Stephen Burrows	Accepted	1	0	0	0	0	0