I've used the library in a real project, and I'm on the mailing list. FYI, there doesn't seem to be much development activity going on, nor is it so perfect and complete that further development is unneeded. That's not to discourage anyone from using it, since it's the only JS lib I know that fills the same niche, just to let you know you may need to get your hands dirty. (I've got a patch waiting for integration but not enough attention available to test it for use cases that are not mine and really push it through. If you do have the interest and bandwidth to polish whatever improvements you make, you could probably help quite a bit.)
Since it sounds like a number of people are maintaining local patches to this library, might it make sense to fork it on GitHub to try to get some additional contributors onboard?
I had the same experience, and we ended up having to patch the core library to get our desired specific result too. It's pretty cool, but it hasn't been updated in a long time and it could really use some fleshing out.
There's another date formatting library if you're using Prototype, that I've used for a few things (although I have to say, I like the OP better). It was kind of hard to track down and doesn't seem to have any continuing support, but is used as part of this nice date picker:
Simon Willison used to have a demo and code for a date (no time) parser which was pretty cool a few years back. No idea if further work has been done on it.
My patch (which can be found discussed in the mailing list) provides a callback hook to modify the final result given the parsed details. I use it to modify assumptions: e.g., if you just type a year, for the final output, the library assumes the rest of the date should be jan 1, but if this field is the end of a date range, it should probably be dec 31 since "burglaries from 2001 to 2002" means the burglaries in 2001 and in 2002. I think it's an important function, and the original author agreed, but neither of us has had the time to test and time everything for all the relevant codepaths to make it into the library.
Other posters have had other complaints about missing functionality--some struck me as reasonable, some not so much--but I haven't kept track.
IT SHOULD NOT PICK A DAY! It should return (2010, 6) -- with no precision implied beyond the input.
This is a major personal hobby-horse of mine, and I don't know of a library that does all of what I want by default. The constructor for datetime in Python's standard library comes very close:
All of the time components have no implied precision beyond the input you've given -- "2009-06-04 3pm" is never implicitly upcast into "2009-06-04 15:00:00 UTC". This is awesome.
Unfortunately the date object used internally does not allow for partial precision, so datetime doesn't expose it.
and i feel like an idiot. didn't realize that today was the 4th. i would imagine that June 1 would make more sense though...but thats pretty nit picky.
I guess it's hard to give an answer to an ambiguous input that will please everyone. Personally I would have expected the 1st of the month.
It seems unusual that "next June" and "last June" both pick the 4th of the month (today's date); but just "June" gives the 1st of the month.
Also "next June" gives "Friday, June 04, 2010 12:00:00 AM" so it picks the day of the month based on today; but the time of day doesn't depend on the time now.
my (available on the mailing list but not integrated) patch for the library gives you a callback into just that point in the process where the library has parsed out what it can but hasn't filled in defaults yet, so you can insert the assumptions that make sense for your application and not have to rely on the default ones.
