Opened 11 years ago

Closed 10 years ago

Last modified 9 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: UI/UX:

Description

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 11 years ago by Jacob

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

comment:2 Changed 11 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 11 years ago by Jason Huggins

darn those homonyms...

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

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

comment:4 Changed 10 years ago by Lawrence Oluyede

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

from dateutil.parser import parse
parse("Tuesday")

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

for example...

See: http://labix.org/python-dateutil#head-c0e81a473b647dfa787dc11e8c69557ec2c3ecd2

comment:5 Changed 10 years ago by Adrian Holovaty

See #3113 for some discussion of parsing dates.

comment:6 Changed 10 years ago by (none)

milestone: Version 1.0

Milestone Version 1.0 deleted

comment:7 in reply to:  4 Changed 10 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 10 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