Invalid Date
How are we supposed to check a parsed Date in 0.8, when Date.IsValid and .Empty are gone? This does not work as expected, because it's not null:
if (null == Date.Parse("wtf")) [there is another bug here, fix gets pushed soon]
if (null == new Date("wtf"))
I am now using this:
if ("Invalid Date" == Date.Parse("wtf").ToString())
Bummer - Not compatible to .Net
Date exists because the semantics of dates are different in script from DateTime in .net. The latter is a value type. There are also some differences in things like one being 1-based in month numbers vs. other being 0-based.
Use null for Date.Empty. One way to check for invalid dates is the following:
isNaN(Date.parse('wtf')
Perhaps IsNaN should be added to Script type to enable this.
Ok, that get me on the road. For the moment I am doing this:
if (Number.IsNaN(selectedDate.GetTime()))
Updated your parseDate addition to return NaN for invalid dates so it is consistent with parseInt/Float... and added Script.IsNaN that allows you to check for NaN results from parsing.
pulled and used it - it's a reasonable approach to return NaN to be able to distinguish unsuccesfull parsings. OT BTW: maybe you didn't see - please consider my comment on #295
I'd personally prefer having Date.Parse() return null or having a Date.IsValid(). Using Script.IsNaN feels like a kludge. Thoughts?
Hi Steve,
I'll admit, this is odd. I was trying to go for symmetry with number parsing, and isNaN might be reasonable for that, but seems unnatural for use with Date instances.
Any thoughts on returning "undefined" instead of null, given null could actually be a valid date (not from parsing dates, but in general)? Simplified truthy/falsy checks should work with both null and undefined. And undefined interestingly enough isNaN returns true for undefined...
I like the "undefined" approach. Seems like a compromise that addresses all of the concerns mentioned in this thread.