Consider reopening ticket #11385

84 views
Skip to first unread message

Andres Osinski

unread,
Jan 7, 2014, 7:53:35 PM1/7/14
to django-d...@googlegroups.com
Hi everyone, I wanted to bring up a request: Ticket #11385 dealt with Django's DateTimeField being unable to handle ISO 8601 date formats.

At the time it seemed reasonable to not support this feature given, however, given the proliferation of web service APIs that return dates using this format, it is natural to use forms to validate the outputs of such services, and having it not baked in while depending on strftime's formatting behavior (which seems to fail tremendously for such datetime formats) makes working with such data very awkward.

I can volunteer to do the bulk of the effort if there's any chance to have a more experienced member of the community go over my work to make sure a decent patch can be submitted.

Cheers

--
Andrés Osinski

Aymeric Augustin

unread,
Jan 8, 2014, 1:47:23 AM1/8/14
to django-d...@googlegroups.com
Django’s DateTimeField parsing code is really targeted at values typed by humans. It doesn’t handle time zones because humans don’t tend to write them down :)

Wouldn’t it be easier to write an ISODateTimeField? It could take advantage of django.utils.dateparse.parse_datetime, which parses an ISO datetime reasonably fast and handles time zone offsets.

-- 
Aymeric.



--
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.

Marc Tamlyn

unread,
Jan 8, 2014, 3:17:23 AM1/8/14
to django-d...@googlegroups.com

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.

Reply all
Reply to author
Forward
0 new messages