This is rather slick. I've used Perl's Date::Manip. It would be nice to move that to the browser but Date::Manip still seems to do a better job. For instance, Date::Manip will resolve "First tue in nov" or "third wed in june" while datejs doesn't. The kiko date parser worked really well. I understand they wrote it themselves?
Try "next friday at 1700" and you get "Wednesday, November 30, 3707 0:00:00 AM"
So it fails a simple test (24hr clock). [0]
But it is a nice idea. You get real time feedback and so you can test if it works. Now would I use it for my blog engine? Maybe. Would I use the source? I looked at the code [1] and the structure looks good but I cannot read the code. It looks like it's all on one line and is not readable. What's the use if I can't enjoy reading it? It's free software, but I can't read it to fix it.
for non-minified source you probably need to checkout the source from their repository instead of downloading releases.
I don't think perl is an acceptable replacement for javascript in a web application. The idea here would be to date validation or manipulation without communicating to a server.
"... for non-minified source you probably need to checkout the source from their repository instead of downloading releases ...
Didn't try this, thanks. Why would the releases [0],[1] be minified? I would have thought the source would be untouched. Who cares if it's 2 X the current download? .... some time later: I've just tried "svn checkout http://datejs.googlecode.com/svn/trunk/ datejs-read-only" I've just checked out revision 93 and the source code for datejs-read-only/src/core.js looks exactly like the shot of the source [2] for the Datejs-all-Alpha/src/core.js [3] The svn release is the same.
Now I admit I could just as easily contact the author to get a non-minified version. Why do I have to (or need to) ask permission?
Find a way around the ambiguity. Either a preference record, local URL, "Did you mean?" response, etc.
Any attempt at helping your user is better than "No One's Home".
This is an old problem, but always an interesting example. I like to think I can accept almost anything from my user in a date field and know what they meant. For September 2, 2007, they should be able to type any of the following: 090207, 0902, 9/2, 9/2/7, 92. My users have also appreciated things like "T" for today, "Y" for yesterday, and of course, "" for today. The year and month should always default to the current. I could go on and on...
When I saw this post, I got excited because I (like almost everyone else) have always struggled with this one. So I put in the simplest case and it couldn't handle it. Oh well.
Yeah, I agree that you should be able to do all of those examples, but if I wanted 2/9/7 to mean the same thing; there would need to be some sort of addiditional indication that I go day month year, (september second is a good example, september 13th would have been unambigious)
http://search.cpan.org/~sbeck/Date-Manip-5.48/Manip.pod