LsIsDate not checking for validity correctly

This is a case of the docs being wrong.  A date in CF is a java.util.Date, and that has a maximum year of [the size of a Long] - 1900, as demonstrated here:

<cfoutput>#createObject("java", "java.util.Date").init(createObject("java", "java.lang.Long").MAX_VALUE)#</cfoutput>

For me, this outputs:

{ts '292278994-08-17 07:12:55'}

So if I was to pass lsIsDate() a value of 3/4/292278994, that would be a TRUE result.  However using 3/4/292278995 (where I have overflowed the year) would be a FALSE result.

CF is notably bad at converting [anything] to a date, as it is far far far too forgiving in what it will consider a date.  For example as far as CF is concerned "1,2" is a date (Jan 2 of the current year).  And this is obviously ludicrous: there is no sensible situation in which "1,2" might be considered a date.  So my advice is: don't even try to use these parsing and validation functions CF provides: they'll accept too many false positives.

Instead, don't allow users to enter dates in these formats, instead have some manner of date-selection mechanism which passes the components separately and in a controlled fashion.  So like a calendar picker, or separate selects for yyyy, mm, dd.

Another thing you could do is perform your own prevalidation.  If you want to only accept dates up to year 9999 (although how AD 9999 is any more likely to be valid data than 292278994 is questionable), then make sure the year part is <10000 before you decide to accept it.  That said, it would be strange for most apps that one would want any year... Are you as interested in what happened in the first century CE as you are the 37th century CE?  Or is it more likely going to be a range within a human or business lifetime?  It depends on the app, sure, but in general I think +/- 100 or so years would be more likely what one would want.  And for a lot of purposes, a far narrower range than that.

--

Adam