In the latest version 2.3.2, the order of the parsers have changed and this caused the shortDate to evaluate first - which is a problem for larger numbers, such as:
which will get parsed as shortDate (well, any number that has two commas in it).
I have just moved "digit" above "shortDate" to solve the problem.
Setting the usNumberFormat option to false (ref) should fix this problem.
Well that won't fix it. This is the US number format (1,234,354.43), so setting it to false will not interpret them as numbers then.
The problem is that the shortDate was moved up in the chain, and thus numbers with two comas (such as 24,125,769) will be parsed as shortDate.
Ahh ok, I'll have it fixed in the next patch. Thanks for reporting it!
shortDate detection update - fixes issue #76
Ok, the fix is now available in v2.3.5. Thanks for reporting this issue!