date format - Coldfusion 10 DateFormat Issue

Question

I am using the DateFormat function to convert dates to this format: yyyy-mm-dd. This is the original format of the date: dd-mm-yyyy. Below is a snippet of the code:

<cfset newdate = #DateFormat(Trim(mydate), "yyyy-mm-dd")# />

The problem is that I get different results for different dates. For example:

• If my original date is: 15-05-2013 (dd-mm-yyyy)
• The result is: 2013-05-15 (yyyy-mm-dd)

However, if I change the input and:

• The original date is: 01-05-2013 (dd-mm-yyyy)
• The result is: 2013-01-05 (yyyy-dd-mm)

Any help or guidance as to what is wrong would be highly appreciated.

Answer 1

I disagree with the other answer. The real cause of the problem is that DateFormat is not designed to handle non-US date strings.

The standard CF date functions always use U.S. date parsing rules. That means when you pass in an ambiguous date string, like 01-05-2013, it is parsed according to U.S. English date conventions. In this case, month first ie "mm-dd-yyyy". So the result will always be January 5th, not May 1st.

In some cases you get lucky. With the string 15-05-2013, there is obviously no 15th month, so CF/java must swap the month and day automatically, rather than throwing an error. That is why it seems to handle some dd-mm-yyyy date strings correctly, but not others.

If you want to parse non-US date strings, you should use the LS (Locale Sensitive) date functions instead. However, according to the docs dashes ie "-" are not a standard date separator in most non-US locales: only Dutch and Portuguese (Standard). So you would either need to change the separator OR use one of those two locales when parsing the date:

        lsDateFormat( myDate, "yyyy-mm-dd", "pt_PT")

Side note:

As an aside, DateFormat does expect a date object. However, like most functions in CF it is flexible enough to accept a date string as well. That allows you to use it as a lazy shortcut to convert from date string => date object => then back to (formatted) date string again. Using date objects is preferable (and you really should validate date strings as well) but that is another conversation altogether ...