return null if can't parse a date about date

[davidkaneda]

@tkreis I implemented some tests locally to better test for invalid strings, and your fix mentioned above (which is accurate), but it breaks the following two tests: "this year" and "this month."

I tend to think date.js in general could benefit from some more direction in regard to the purpose of the library, which, as I see it, is to provide an exact timestamp from a fuzzy bit of language. If this is the case, "this year" and "this month" should probably be removed anyway, as they're too ambiguous. Same with items like #11. On the other hand, the lib itself should probably support "Now."

Any thoughts?

[ianstormtaylor]

+1 this is frustrating when you want to specifically only parse with Date.js when it's able to do it, and otherwise fallback to something else.

[matthewmueller]

hmm, I think this line covers this case:

https://github.com/MatthewMueller/date/blob/master/lib/parser.js#L50

Basically if the date hasn't changed at all, throw an error (in line with the Date(invalid) does). I'm not sold on throwing an error, we could maybe go with null instead. What's the input that you're using?

[dominictarr]

ah, I noticed that in the code, but I couldn't get it to throw.
I tested this with nonsense 'aoneuhracr', but it returns the current time.

[tkreis]

@matthewmueller If your intent was to compare dates it won't work, if your intent was to compare objects it works. By changing the line to it'll compare if the dates are actually the same.

d.getTime() == this.date.date.getTime()