locale specific dateformatting buggy? - coldfusion

Question

We have been running into date formatting issues for over a year now. We have a EU formatting in our database (dd/mm/yyyy) and we also want to output that on our website. Problem is that we're running the dates through the date formatting functions of coldfusion, to be certain we're always outputting our dates the same way (and for other reasons).
That's where it goes wrong. The code below outputs 2 different dates, where we would expect the same date.
<cfoutput>
#LSDateFormat('01/02/2015', 'dd/mm/yyyy', 'nl_BE')# <br />
#LSDateTimeFormat('01/02/2015', 'dd/mm/yyyy HH:nn', 'nl_BE')#
</cfoutput>
// output
// 01/02/2015
// 02/01/2015 00:00
I have tried on trycf.com, using all different available engines.
Please explain to me what I'm doing wrong here. Or tell me this is a bug that no-one ever has mentioned. But I would prefer me being wrong here..

Answer 1

I think you are misunderstanding the 'format' functions. They are designed for presentation. Their purpose is to convert a date object into a string: ie LSDateTimeFormat (date , mask). The 'mask' is used to determine what that output string looks like, not to parse the input. Notice if you pass in a date object, NOT a string, it works exactly as you expected? The result is 01/02/2015 00:00
dateObject = createDate(2015,2,1);
writeDump("dateObject = "& LSDateTimeFormat(dateObject, 'dd/mm/yyyy HH:nn', 'nl_BE'));
Yes, CF allows you to be lazy, and pass in a string instead. However, CF must still convert that string into a date object before it can apply the mask - and you have no control over how CF does that. When you use strings, you are essentially leaving the interpretation of that string entirely up to CF. In this case, CF interprets the ambiguous string "01/02/2015" according to U.S. date rules ie month first. That produces January 2, 2015. Hence why the output of the mask dd/mm/... is 02/01/2015 00:00. So in essence, what your code is really doing is this:
// parse string according to U.S. rules - mm/dd/yyyy
HowCFInterpretsYourString = parseDateTime(dateString);
LSDateTimeFormat(HowCFInterpretsYourString, 'dd/mm/yyyy HH:nn', 'nl_BE');
Results:
HowCFInterpretsYourString = {ts '2015-01-02 00:00:00'} <=== January 2nd
LSDateTimeFormat = 02/01/2015 00:00 <=== Day = 2, Month = 1
If you do not want CF doing the interpretation for you, pass in date objects - not strings.
As for why LSDateFormat's behavior seems inconsistent with LSDateTimeFormat, I do not know. However, strings are ambiguous. So when you use them instead of date objects, well ... expect the unexpected.
We should just convert to the correct date object first and then format using the normal dateFormat method.
Just because you are only using the format functions to output the numeric date parts, does not mean that is all they do ;-) The format functions also output names, which are locale specific. For example, "MMMMM" might produce "September" or "septiembre" depending on the current locale. There are also other region specific rules, such as the placement of "month" and "day" and the exact capitalization of names. The standard Date/TimeFormat functions always use U.S. date conventions. Whereas LSDateTimeFormat uses whatever locale is supplied. In this specific case, there is not much difference because you are only outputting the numeric date parts:
Numeric date parts (only)
dateObject = createDate(2015,2,1);
writeDump("LSDateTimeFormat = "& LSDateTimeFormat(dateObject, 'dd/mm/yyyy', 'nl_BE'));
writeDump("DateTimeFormat = "& DateTimeFormat(dateObject, 'dd/mm/yyyy'));
Results:
LSDateTimeFormat = 01/02/2015
DateTimeFormat = 01/02/2015
However, for other formats there is a big difference. A date object may not be tied to a locale, but a string representation of a date is .. so the two functions are not interchangeable.
Date Names:
dateObject = createDate(2015,2,1);
writeDump("LSDateTimeFormat = "& LSDateTimeFormat(dateObject, 'full', 'nl_BE'));
writeDump("DateTimeFormat = "& DateTimeFormat(dateObject, 'full'));
Results:
LSDateTimeFormat = zondag 1 februari 2015 0.00 u. UTC
DateTimeFormat = Sunday, February 1, 2015 12:00:00 AM UTC
"EU formatting in our database (dd/mm/yyyy)"
Not sure what you mean by that. Date/time objects do not have a format. Your IDE may display them as human friendly strings, but the date values themselves are stored as numbers. Based on what you described, it sounds like either the values are stored as strings OR are being converted to strings, which would explain the results. Instead, store the values in a date/time column, then retrieve them and pass them into the function "as is" and it should work fine.

Answer 2

I use English (U.S.) locale conventions, so I can use ParseDateTime(), DateFormat() or DateTimeFormat()... but since your dates are UE, you must use LSParseDateTime() on the string that represents the date and the results should be consistent
<cfset D = "01/02/2015">
<cfoutput>
0. #D#<br />
1. #DateFormat(D)#<br />
2. #ParseDateTime(D)# (Parse default US)<br />
3. #LSParseDateTime(D,'en_GB')# (Parse en_GB)<br />
4. #LSDateFormat(D, 'dd/mm/yyyy', 'nl_BE')# (no parsing, default US)<br />
5. #LSDateTimeFormat(D, 'dd/mm/yyyy HH:nn', 'nl_BE')# (no parsing, default US)<br />
6. #LSDateFormat(ParseDateTime(D), 'dd/mm/yyyy', 'nl_BE')# (parsed as default US)<br />
7. #LSDateTimeFormat(ParseDateTime(D), 'dd/mm/yyyy HH:nn', 'nl_BE')# (parsed as default US)<br />
8. #LSDateFormat(LSParseDateTime(D,'en_GB'), 'dd/mm/yyyy', 'nl_BE')# (parsed as en_GB locale)<br />
9. #LSDateTimeFormat(LSParseDateTime(D,'en_GB'), 'dd/mm/yyyy HH:nn', 'nl_BE')# (parsed as en_GB locale)<br />
</cfoutput>
Results for text string "01/02/2015":
0. 01/02/2015
1. 02-Jan-15
2. {ts '2015-01-02 00:00:00'} (Parse default US)
3. {ts '2015-02-01 00:00:00'} (Parse en_GB)
4. 01/02/2015 (no parsing, default US)
5. 02/01/2015 00:00 (no parsing, default US)
6. 02/01/2015 (parsed as default US)
7. 02/01/2015 00:00 (parsed as default US)
8. 01/02/2015 (parsed as en_GB locale)
9. 01/02/2015 00:00 (parsed as en_GB locale)
You could use SQL to re-format the query data to standardize on US locale conventions:
http://www.sql-server-helper.com/tips/date-formats.aspx
SELECT CONVERT(VARCHAR(10), DateField, 101) AS USDate_MMDDYYYY
Either way, I recommend creating a UDF so that you can modify this rule in one single place in case you need to make any any future modifications.