Next Friday at 3pm not working correctly

[LarryCl]

I'm running into the same problem noted here
http://groups.google.com/group/datejs/browse_thread/thread/41e29be1cda61708/7f57c2be318d25fb?lnk=gst&q=next

Examples: (today is Thursday March 26)
3pm next friday => Friday, March 27, 2009 12:00:00 AM
3pm friday => Friday, March 27, 2009 3:00:00 PM
friday at 3pm => Friday, March 27, 2009 3:00:00 PM
next friday at 3pm => Friday, March 27, 2009 12:00:00 AM
next friday 3pm => fails

I am using the latest date.js code version: 1.0 Alpha-1, date:
2008-05-13

Is this a bug or am I missing something?

[LarryCl]

Also found the following:

7:40pm tomorrow => Tuesday, March 31, 2009 12:00:00 AM
tomorrow 7:40pm => fails
tomorrow at 7:40pm => Tuesday, March 31, 2009 12:00:00 AM

My comment on this is, huh?

Is this project still under active development? It seems like there
are a bunch of bugs that have been documented for a while but there
have not been any updates to the code for almost a year. I'd try to
fix them myself, but I'm not a good enough Javascript coder to fix the
code.

[Dr J R Stockton]

On Mar 30, 9:58 pm, LarryCl <larrycla...@gmail.com> wrote:
> ... I'd try to

> fix them myself, but I'm not a good enough Javascript coder to fix the
> code.

Here's standard, slightly tested JavaScript to do it (but to after
3pm !) ; I assume "next Friday" means ahead by 1 to 7 days. If it
means "Friday next Week" then the Week must be defined : as
International Standard, or otherwise.

Fri = 5
Today = new Date()
DoW = Today.getDay()
Today.setDate(Today.getDate() + 1 + (7-1 + Fri - DoW)%7 )
Today.setHours(15, 1, 2, 3)

The first 1 and the %7 assure moving ahead by 1-7 days; the second 1
compensates the first; the first 7 assures a positive operand for %;
the rest is obvious.
<URL:http://www.merlyn.demon.co.uk/js-dates.htm> ff.

--
(c) John Stockton, near London, UK. Using Google, no spell-check.
Mail: J.R.""""""""@physics.org or (better) via Home Page at
Web: <URL:http://www.merlyn.demon.co.uk/>
FAQish topics, acronyms, links, etc.; Date, Delphi, JavaScript, ....|

[LarryCl]

Thanks John; In my application, I've already special-cased many of the
quirks/bugs I've found in datejs, but I always appreciate
suggestions. What I meant by 'fix the code' was fixing the datejs
date parsing algorithms (which I took a look at and quickly realized
were beyond my javascript skills)

It seems to me that datejs is solving two distinct use cases:
1) complex date arithmetic using javascript objects
2) parsing and interpreting dates presented in arbitrary natural
language

#1 appears to be very robust; it's the #2 use-case that appears to be
to be quirky/buggy. My application is using datejs for #2, hence I'm
encountering a lot of these bugs. As I discover them, I am writing
work-around code in my application, but they should really be fixed in
the library itself.

[Dr J R Stockton]

On Apr 2, 3:11 pm, LarryCl <larrycla...@gmail.com> wrote:

> It seems to me that datejs is solving two distinct use cases:

^^^^^^^ wrong word, AFAICS

> 1) complex date arithmetic using javascript objects
> 2) parsing and interpreting dates presented in arbitrary natural
> language
>
> #1 appears to be very robust; it's the #2 use-case that appears to be
> to be quirky/buggy.  My application is using datejs for #2, hence I'm
> encountering a lot of these bugs.  As I discover them, I am writing
> work-around code in my application, but they should really be fixed > in the library itself.

Your #2 is fundamentally impossible, for two reasons :
A) Natural language is frequently ambiguous even in a single
geographical area,
B) A date string deemed unambiguous in one country and its
satellites will be deemed unambiguous with a different meaning in many
other countries.

And that's assuming that the date is Gregorian. Historians have to
deal with the Julian Calendar and its transition; and non-Gregorian
calendars are in daily use in many countries in or influenced by Asia.

Did you find any reasonable Gregorian date formats that code on my
pages cannot handle? YYYYDDMM is not reasonable, and may need
preprocessing by a RegExp replace or substitute.

[LarryCl]

John, I think we are talking about two different things here.
With regard to the natural language parsing of dates, yes, if the
problem is unbounded to include any arbitrary date description in any
language, then yes, the problem is extremely difficult.

However, within the bounds of datejs there are some specific "natural
language" expressions that it should be able to parse. These are even
documented on the datejs home page. And what I have pointed out in
this thread is these are buggy.

Look at these examples that are currently returned by datejs. Are you
suggesting that this is expected behavior?

3pm next friday => Friday, March 27, 2009 12:00:00 AM BUG
3pm friday => Friday, March 27, 2009 3:00:00 PM CORRECT
friday at 3pm => Friday, March 27, 2009 3:00:00 PM CORRECT
next friday at 3pm => Friday, March 27, 2009 12:00:00 AM BUG
next friday 3pm => fails BUG
7:40pm tomorrow => Tuesday, March 31, 2009 12:00:00 AM BUG
tomorrow 7:40pm => fails BUG
tomorrow at 7:40pm => Tuesday, March 31, 2009 12:00:00 AM BUG