--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BxF-PzQ1Vg4aTReu0ZW%3DdOAc2HCzysaLN73%3Dk%3D9-2%2BQwWv8Ow%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
I'm a little unsure whether that argument continues to hold about users writing times and dates. I don't know of that many sites which don't use a datepicker of some description at least for dates, and even the admin has some client side help for picking times.
It seems reasonable that one field should be able to support both versions - this would also mean that an auto generated ModelForm is appropriate for use in API code, or in progressive enhancement situations where you wish to support AJAX from some arbitrary JS and human input (hey, and curl) all at the same endpoint.
I have personally had to write date parsing into my API code or AJAX endpoint code on multiple occasions to work around this. So, unless there is a good technical reason why this is hard to do, I would like it to be supported.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/97F059CD-54D8-4B5F-A047-CE0AB3AF03DE%40polytechnique.org.