Opened 20 years ago

Closed 18 years ago

Last modified 18 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
Pull Requests:18602 build:failure, 18041 build:success, 19192 merged, 18666 merged, 17629 merged, 18360 merged, 18285 merged, 17701 merged, 17289 merged, 17153 merged, 17140 merged, 17184 merged, 17013 merged, 16965 merged, 16971 merged, 16739 merged, 16763 merged, 16506 unmerged, 16405, 16450, 16467, 16226, 15887, 15810, 15821, 10544, 15532, 15452, 15226, 14944

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

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

comment:2 by Jason Huggins, 19 years ago

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 by Jason Huggins, 19 years ago

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 by Lawrence Oluyede, 18 years ago

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 by Adrian Holovaty, 18 years ago

See #3113 for some discussion of parsing dates.

comment:6 by (none), 18 years ago

milestone: Version 1.0

Milestone Version 1.0 deleted

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

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

Resolution: fixed
Status: assignedclosed

This has been fixed in newforms.

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