Re: #6966: It's impossible to specify input_formats for DateTimeFields in ModelForms

[johannes.spielmann@…]

Well. Sorry to open a new ticket for this, but it seems you don't want to let me post to the other one, namely #6966. So read my comments here:

"Let me rephrase my complaint:

There is no way to specify the way date and time strings work for locales other than the US. Very nice. Date and time string interpretation should be a function of the locale, not of specific fields -- which is not the case here.

I know that I can forgo the benefits of using ModelForms for DateTimeFields by manually inserting DateTimeFields and specifying an input format. But I already specified the locale and the fields.

Do you find it acceptable to repeat all this information for each and every DateTimeField? Is that the intention behind ModelForms?

"

[James Bennett]

Who says you have to repeat it for each and every field? It'd be fairly easy to write a custom form field that does precisely what you want, and reuse it over and over; in the meantime, ModelForm isn't meant to automatically handle custom requirements. If you need assistance with this, please consider asking on the django-users mailing list.

[johannes.spielmann@…]

This is neither an issue of automatically handling custom requirements
nor and form of coding problem on my end. This is about making the
following work:
"In this case, it would be redundant to define the field types in your
form, because you've already defined the fields in your model." [1]
As of now, the above sentence is true for locales that have the same
date/time format as the use, and false for everywhere else. So, basically
this is an internationalization issue.

Alright, since you don't seem to understand the issue here, let
me show you some code example:

models.py:

class MyModel(Model):
   ...
   someDateTimeField = fields.DateTimeField(verbose_name="some datetime field",
						help_text="some help text",
						required=value,
						other_attrs=...)
   ...

If you are using your locale (or any other that happens to
have the same date/time conventions), creating a form for this model will be:

class MyModelForm(forms.ModelForm):
	class Meta:
		model = MyModel

That's it. Three lines.

However, if the application you are writing uses any other locale, this
becomes the following:

class MyModelForm(forms.ModelForm):
	class Meta:
		model = MyModel

	# per the documentation
	class MyDateTimeField(forms.DateTimeField):
		def __init__(self, *args, **kwargs):
			if not 'widget' in kwargs:
				kwargs['widget'] = forms.DateTimeWidget(input_formats=LOCALE_DEFAULT_DATETIME_FORMAT)
			super(CommentWidget, self).__init__(*args, **kwargs)

	someDateTimeField = forms.MyDateTimeField(label="some datetime field",
						  help_text="some help text",
						  required=value,
						  other_attrs=...)

About 13 lines. And for each DateTimeField in your Model, you have to add
at least another three lines -- that is, duplicate another three
lines.

How is this in any way DRY? How is this sane, actually? Code that does
the same thing for different locales is so vastly different?

No, I don't think that should be the way it is. It should be something
like this:

class MyModelForm(forms.ModelForm):
	class Meta:
		model=MyModel
		LOCALE_DEFAULT_DATETIME_FORMAT = _(some_value)
		LOCALE_DEFAULT_DATE_FORMAT = _(some_value)
		LOCALE_DEFAULT_TIME_FORMAT = _(some_value)
		# note the _, since we want to be able to localize this

Or maybe it would even be appropriate to add an entry to the settings file
containing the DEFAULT formats, since it is a global setting.
This shouldn't be too hard to do. If you want, I can code this up for you.

Oh, and please stop your condescending RTFM-attitude. I did read the manual
and I did read the code for ModelForms and it does not handle this case,
which I think it should. If you have any arguments why it shouldn't (other
than "this is a customization issue, RTFM n00b"), I would be really interested
in hearing them.

[anonymous]

Forgot to add the URL:
[1] ​http://www.djangoproject.com/documentation/modelforms/

[anonymous]

I have to agree, you guys should stop closing this ticket as invalid, international date handling in Django is still a joke
E.G: #6231

[Jacob]

This is a subset of #7980, which addresses this and other shortcomings in i18n.

[(none)]

Milestone 1.0 maybe deleted