LsIsDate not checking for validity correctly

Question

I am sure this problem has come up before but I couldn't find any discussions on this forum relevant to it. Basically I am using a text field to enter dates and validating it using LsIsDate. The problem is that dates that should not be valid are passing as valid and screwing up the forms execution.
For instance:
I am using
<cfset NewLocale=SetLocale("English (Australian)")>
<cfif NOT LSIsDate(attributes.strStartDate)>
   Some error code here
<cfelse>
  <cfset attributes.StartDate = lsParseDateTime(attributes.strStartDate)>
</cfif>
The problem is that dates with huge year values ie. 3/4/20121 are considered valid even though LsIsDate is supposed to only accept year values up to 9999.
Any work arounds for this problem would be hugely appreciated.
Cheers
Aden

Answer 1

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