Today I stumbled upon a strange lsDateFormat issue. On a project I'm currently working on (not THE project ;)) dates are stored in this format: "mm/dd/yyyy". Today, one of the pages started throwing an odd error:

7/29/2009 is an invalid date format.

For some reason this particular date was throwing it off. I also ran a couple of tests to try and figure out where things were going wrong.

view plain print about
1<cfset dtstring = "7/29/2009" />
2
3<cfoutput>
4<p>
5    Is date valid: #isValid( "date", dtstring )#
6</p>
7<p>
8    lsDateFormat, plain:
9    <cftry>
10        #lsDateFormat( dtstring, "long" )#
11        <cfcatch>FAIL</cfcatch>
12    </cftry>
13</p>
14<p>
15    lsDateFormat, fixed?:
16    <cftry>
17        #lsDateFormat( dtstring+0, "long" )#
18        <cfcatch>FAIL</cfcatch>
19    </cftry>
20</p>
21<p>
22    dateFormat:
23    <cftry>
24        #dateFormat( dtstring, "long" )#
25        <cfcatch>FAIL</cfcatch>
26    </cftry>
27</p>
28</cfoutput>

Running the above code I was left with the following output:

Is date valid: YES

lsDateFormat, plain: FAIL

lsDateFormat, fixed: July 29, 2009

dateFormat: July 29, 2009

The first thing that's odd is that the isValid call returns true. ColdFusion recognizes that this is a valid date. Also, passing it to dateFormat works perfectly. Why, then, does sending it to lsDateFormat fail?

The fix I ended up putting in is rather simple. By adding 0 to the string, we are forcing ColdFusion to convert the date to it's integer representation before performing the operation. Once that's done, the original date's format is no longer important.

It's also worth noting that using the ISO format (yyyy-mm-dd) in this case would've also solved the problem. However, in my case, changing the date formats was not a possibility and I had to rely on this "quick-fix".