Datejs: A Truly Slick Date Script | Hacker News Reader

Datejs: A Truly Slick Date Script

mashable.com

11 pointsshayan14 comments

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?

http://search.cpan.org/~sbeck/Date-Manip-5.48/Manip.pod

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.

Dates and times are difficult. For a real alternative try ~ http://datetime.perl.org/?Modules

[0] http://flickr.com/photos/bootload/2070923712/

[1] http://flickr.com/photos/bootload/2070134059/

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?

[0] The svn repository online http://datejs.googlecode.com/svn/

[1] Access to the source http://code.google.com/p/datejs/source

[2] http://flickr.com/photos/bootload/2070134059/

[3] http://datejs.googlecode.com/files/Datejs-all-Alpha1.zip

http://datejs.googlecode.com/svn/trunk/src/ there are 2 versions of each file. The one named file-debug.js contains the non-minified version

"... for non-minified source you probably need to checkout the source from their repository instead of downloading releases. ..."

Damn. Would you believe I checked the only file in the repository that was minified, core.js. The rest it appears are quite readable.

http://abstractnonsense.com/datejs.png

I want to see this check the timezone of the client, and calculate other timezones (unix: PST: next tuesday + 5 years)?

I typed "112807" (the most likely entry by my users) and it responded "No One's Home".

Handle the easy cases first; then get slick.

It should be able to handle any delimitter, even no delimitter at all.

well, other parts of the world standard to DDMMYY, so do you choose in ambiguous cases? not likely.

"so do you choose in ambiguous cases?"

Absolutely!

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".

Certainly, and also, at second thought, having separator characters doesn't make it any less ambiguous either (DD/MM/YYYY || MM/DD/YYYY).

When I said "you" I was speaking for the program, my opinion is that the client should choose as well.

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)

Reply on news.ycombinator.com