Opened 13 years ago

Closed 12 years ago

Last modified 9 years ago

#1646 closed enhancement (wontfix)

[patch][cla needed] strtodate(): "natural language" date parsing

Reported by: dojo@… Owned by: psowden
Priority: high Milestone: 0.9
Component: Date Version: 0.3
Keywords: date parsing dropdowndatepicker format Cc: Adam Peller, mde@…
Blocked By: Blocking:

Description

This patch (format.js-strtodate.patch) adds a dojo.date.strtodate() function that takes a string and outputs a Date. It is an enhanced and adapted version of code originally written by Simon Willison (BSD-licensed) and based loosely on PHP's strtotime() function. It will accept strings in any of the following formats:

"today" (or substring) "tomorrow" (or substring) "yesterday" (or substring) "6th" "6th March" or "March 6" (or month substrings) "6th March 2006" or "March 6, 2006" (or month substrings) "Tuesday" (or substring) "next Tuesday" (or day substring) "last Tuesday" (or day substring) "3/6/06" or "6/3/06" (based on locale) "3/6/2006" or "6/3/2006" "3/6" or "6/3" "2006-03-06" or "2006-3-6"

Month and day names are localized using dojo.date.getNames(). Periods, hyphens, and slashes are accepted interchangeably as separators.

The second patch (DropdownDatePicker?.js-strtodate.patch) patches DropdownDatePicker? to use dojo.date.strtodate() in its input field. It also adds a Boolean restrictInputFormat attribute that, when set to true, restores the old behavior. I've tested in the latest IE6, Safari 2, and Firefox 2RC and it seems to work fine, but I'm still relatively new to OO JavaScript? so someone should probably make sure I didn't do something inefficient...

Attachments (2)

format.js-strtodate.patch (6.3 KB) - added by dojo@… 13 years ago.
Primary patch: adds dojo.date.strtodate()
DropdownDatePicker-strtodate.patch (1.1 KB) - added by dojo@… 13 years ago.
Patches DropdownDatePicker? to use dojo.date.strtodate()

Download all attachments as: .zip

Change History (14)

Changed 13 years ago by dojo@…

Attachment: format.js-strtodate.patch added

Primary patch: adds dojo.date.strtodate()

Changed 13 years ago by dojo@…

Patches DropdownDatePicker? to use dojo.date.strtodate()

comment:1 Changed 13 years ago by Adam Peller

Summary: [patch][cla] strtodate(): "natural language" date parsing[patch][cla needed] strtodate(): "natural language" date parsing

Cool stuff, but I'm not sure we should commit this or use it as the default parse algorithm until it's fully localized, and that might be hard:

1) Terms like "tomorrow" must be localized, as well as word order and various other customs, and I'd imagine there are many 2) Ordinals (like "th") must also be localized 3) ISO and numeric date formats should try to use and/or enhance existing localized code in dojo.date

Also, I'm not sure we have enough CLAs in place for this patch.

comment:2 Changed 13 years ago by Adam Peller

Cc: Adam Peller mde@… added

comment:3 Changed 13 years ago by dojo@…

I have a CLA on file already. The original code by Simon Willison is BSD-licensed (I checked with him via email) though I suppose I could bug him about a CLA.

Maybe include the patch to format.js but change the modifications to DropdownDatePicker? so using strtodate() is not the default, at least until strtodate is fully localized? I can update the DropdownDatePicker? patch accordingly if that's the way to proceed.

comment:4 Changed 13 years ago by guest

Some additional thoughts for the group:

Right now, typing "2/1" will give you February 1, 2006. In many cases (particularly situations where the user is entering a date) what you actually want (typing that in October 2006) is February 1, 2007. Do you think it makes sense to do that universally? To provide some options on the strtodate() function?

And while we're at it, what would you think of my adding a placeholder hint to DropdownDatePicker?? (Text that appears in the input when it has no value.) Maybe default to dd/mm/yy or mm/dd/yy, but let the user override as an attribute. And if you do like the idea, should it be a property of DropdownDatePicker? or its parent?

comment:5 Changed 13 years ago by dojo@…

Argh. Forgot to put my email address on the previous comment but it's me again.

comment:6 Changed 13 years ago by Adam Peller

All interesting ideas. I worry that too many heuristics could make these widgets hard to use and the results hard to predict. I believe we have (or had) a similar ability to set a range for a century so that "55" might be interpreted as 1955 or 2055. I avoided the default value hints problem as well, but I'm not sure what is the best localized solution. We're not going to solve this here. Perhaps we should start a page on the wiki for date parsing and datepicker ideas?

comment:7 Changed 13 years ago by dojo@…

A wiki page might make some sense; there are numerous issues here, and I think it's an area worthy of exploration. Too often today's Web apps rely on popup calendars to make their date entry usable, whereas more robust recognition of entered strings could be a lot more efficient. I'll set up a page when I have a moment.

That said: if there's uncertainty about what the widgets should do, why not include the strtodate() function without any widget modifications (or with a "naturalInput" attribute on the DropdownDatePicker? for opt-in functionality)? Those interested in using it who accept its heuristics can take advantage of it to improve their date input functionality; those who don't like it can ignore it. Seems like a win-win. 'Course I submitted the thing so obviously I'm gonna think it's a good idea.

The current implementation does have a year heuristic built in: 2-digit years before 70 are assumed to be after 2000, whilst 2-digit years after 70 are not. Might make sense to lower the cutoff to support a wider range of birthdates, though.

I've implemented my first suggestion in my local copy: dates entered without years are relative to the current date. If you decide to include it I'll provide an updated patch.

The hint turns out to be a little tricky but not too bad. I can supply a patch if there's interest. Localization...well, I guess it would involve localizing the default value (since it can be overridden as an attribute). I don't know Dojo's localization APIs yet but it's probably something I should look into.

comment:8 Changed 13 years ago by dylan

Milestone: 0.5

comment:9 Changed 13 years ago by bear

I'm the author of a python based library that parses human-readable text and I've been thinking of making a javascript version for our Cosmo project (I work at Open Source Applications Foundation) when one of the dev's pointed me to this ticket.

Would the Dojo project be interested in this also?

my email is bear (at) code-bear (dot) com

comment:10 Changed 13 years ago by jan831@…

localization can be done by adding the dateParsePatterns variable to the localized date & time patterns (gregorian.js). I don't really know how these files are handled in the code exactly , but it's a very similar case to me

comment:11 Changed 12 years ago by Adam Peller

Resolution: wontfix
Status: newclosed

it sounds like this should be pursued as a separate dojox project. we're not going to do this in the core. I still think the i18n issues (both translation and cultural) would be very difficult. Even generating localized versions of 1st, 2nd, 3rd is considered a significant problem.

comment:12 Changed 12 years ago by Adam Peller

for what it's worth, we already handle several of these formats using dojo.date.parse (e.g. 07/16/2007, 2007-16-07, July 16, 2007, etc. but you'd have to explicitly make several passes using the different formats. We don't deal with the 1st/2nd/3rd, etc. as I mentioned, but the relative dates ("next Tuesday", "yesterday", etc.) as well as the 'guessing' heuristics might make a good dojox extension. We deliberately avoided as many of these things as we could to keep the size and complexity of core down (and look at how complex it already is!)

Note: See TracTickets for help on using tickets.