Opened 15 years ago

Closed 14 years ago

Last modified 13 years ago

#8 closed defect (fixed)

Date and time fields should accept multiple formats

Reported by: Adrian Holovaty Owned by: Jacob
Component: contrib.admin Version:
Severity: minor Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Date and time fields should be able to adapt to multiple formats of user input (a la Simon's date parser).

As a basic example, a user should be able to enter "Today" or "Wednesday" for the date and have it converted to the correct format for today's date or this Wednesday's.

For time fields, a user should be able to enter 6pm instead of 18:00.

Change History (8)

comment:1 Changed 15 years ago by Jacob

milestone: Version 1.0
Owner: changed from Adrian Holovaty to Jacob
Status: newassigned

comment:2 Changed 15 years ago by Jason Huggins

Getting this right and bug free in all the corner cases is *hard work*. I just modifed one of my apps (non-Django) to remove choice in date formats and standardized on one format because having so much choice was the route of a lot of bugs. I suggest this doesn't belong on the version 1.0 milestone. The current defaults of ISO date format (YYYY-MM-DD) and 24-hour time are fine for a 1.0 release-- these are sane defaults that people should be able to put up with / live with until a post 1.0 release. But that's just my opinion. :-)

comment:3 Changed 15 years ago by Jason Huggins

darn those homonyms...

1) "route to a lot of bugs..."
2) "root cause of a lot of bugs..."

Take your pick as to which one I meant. :-)

comment:4 Changed 14 years ago by Lawrence Oluyede

What about using dateutil's parse method? Seems to work really well:

from dateutil.parser import parse

datetime.datetime(2006, 12, 26, 0, 0)

for example...


comment:5 Changed 14 years ago by Adrian Holovaty

See #3113 for some discussion of parsing dates.

comment:6 Changed 14 years ago by (none)

milestone: Version 1.0

Milestone Version 1.0 deleted

comment:7 in reply to:  4 Changed 14 years ago by Gary Wilson <gary.wilson@…>

Triage Stage: UnreviewedDesign decision needed

I would say that #3113 supersedes the dates part of this ticket, and newforms allows for date entry in various (non-humanized) formats. Leaving open to decide about the humanizing of times.

comment:8 Changed 14 years ago by Jacob

Resolution: fixed
Status: assignedclosed

This has been fixed in newforms.

Note: See TracTickets for help on using tickets.
Back to Top