

Datejs: A Truly Slick Date Script - shayan
http://mashable.com/2007/11/27/datejs-a-truly-slick-date-script/

======
ratsbane
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>

------
bootload
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/>

~~~
gregwebs
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.

~~~
bootload
_"... 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>

~~~
gregwebs
<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

------
abstractbill
<http://abstractnonsense.com/datejs.png>

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

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

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

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

~~~
izak30
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.

~~~
edw519
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.

~~~
izak30
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)

