#13621: Regression in 1.2.1. date/time widgets are printing their values with an
invalid format
-------------------------------+--------------------------------------------
Reporter: bufke | Owner: jacmkno
Status: assigned | Milestone:
Component: Forms | Version: 1.2
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 1
Needs_better_patch: 1 |
-------------------------------+--------------------------------------------
Comment (by russellm):
I've just uploaded a candidate patch for this issue. This fixes point (1)
and (2) from my previous post.
However, on reflection, issue (2) requires some more thought.
When we talk about date/time formats, there are actually two different
formats under discussion:
a. The format that will be used to display dates to the user.
b. The list of formats that will be accepted as user input.
The issue at hand is whether specifying an input format specified on the
field (which is then used as an accepted format for input) should imply
anything about the way the widget displays data.
In order for form resubmissions to work, (a) must be part of the list
provided by (b), but this hasn't been enforced historically. This has
worked because the default YYYY-MM-DD and HH:MM:SS formats have always
been accepted input formats, so it didn't matter if you specified
additional input_formats; the defaults would always be readable.
However, now that we have L10N support, there's no simple 'default' date
format, and if the user manually specifies an input_formats list on a
field, there's no guarantee that the locale will output dates in a manner
compatible with this format.
The fix for this is to ensure that if input_formats is specified, the
first format in that list is used as the widget's display format.
Historically, the onus would have been on the developer to also provide a
widget that explicitly named that format (i.e.,
DateField(input_formats=[...], widget=forms.DateWidget(format='...')) ).
I'm not entirely happy with this fix, as it exposes even more of the
internals of widgets into the implementation of Field.
It's also worth noting that this is something that most users won't have
to deal with -- if you set up INPUT_DATE_FORMAT et al as a system wide
setting, the default format of the widget will be the first
INPUT_DATE_FORMAT value. The failure to do this was the regression that is
the subject of this ticket.
So - the question becomes: do we actually want to fix (2) at all? Or
should we treat this as an edge case (i.e., if you specify input_formats,
then the onus is on you to make sure you specify a widget with a matching
format)? I'm inclined to take the second approach, but I'd like to hear
from others before I commit. If you want to see what the patch would look
like without (2) being fixed, just revert the changes to
django/db/fields.py. Some of the test cases will fail as a result, but for
obvious reasons.
--
Ticket URL: <http://code.djangoproject.com/ticket/13621#comment:18>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
