Order of formats in Date.parseExact()?

[GoogleCodeExporter]

Seems to be a problem in .parseExact() somewhere, or maybe it's in
Parser.finishExact. For example...

// returns null
Date.parseExact("November 2007", ["MMMM d", "MMMM yyyy"]);

// Switch the format order, and a valid date is returned
Date.parseExact("November 2007", ["MMMM yyyy", "MMMM d"]);

Original issue reported on code.google.com by geoff%co...@gtempaccount.com on 26 Nov 2007 at 6:10

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I just ran into this too using ['H:mm', 'h:mm tt'], and delved into the code a 
bit.  The problem was that parseExact with an array of formats conceptually 
works in two stages:
1) Find the first format in the array which successfully parses the date. (the 
"any" function) If none, fail.
2) Check if the parse had any leftover text.  If so, fail.

Here, given the time '1:30 PM', the parser matched 'H:mm' with 'PM' left over, 
and failed without trying the second format.  Similarly, in your case, the 
parser matched "November 20" with "07" left over, returning a failure.

The right solution is probably to use an "all" function instead of "any", but 
when some formats are strictly longer than others, putting the longer ones 
first in the array should do the trick.

Original comment by cjmal...@gmail.com on 17 Jun 2011 at 5:52

[GoogleCodeExporter]

I think the attached file fixes the bug (adding an allformats function and 
modifying getParseFunction).

-Chris Maloof

Original comment by cjmal...@gmail.com on 20 Jun 2011 at 4:31

Attachments:

• date.js.diff
• date.js

[GoogleCodeExporter]

Patched and fixed in my current fork: https://github.com/abritinthebay/datejs/

Original comment by darkcr...@gmail.com on 10 Sep 2013 at 10:10