Passing value in argument dd/mm/yyyy but receiving wrong date CF2021

[Faizan278243197lsr]

The date value passing through .cfm file dd/mm/yyyy ("01/03/2023") while reciving value in CFC file

<cfset actualdt=lsdateformat('01/03/2023','dd-mmm-yyyy')>

<cfdump var="#actualdt#">

outcome comes 03/Jan/2023 but it should come 01/Mar/2023.

Please guide me how to come out from this issue. 

[Charlie Arehart]

This is a known issue: a compatibility change rather than a bug.

Update: I realize now that my first reply here was solving a problem that Faizan does not have. My apologies everyone. I've offered a new reply below, and have struck out the above. Still, I leave the rest here as it explains Faizan's replies and our back and forth.

For a bit more on that d vs D change in cf2021,  see Adobe's technote:

https://helpx.adobe.com/coldfusion/kb/dateformat-function-coldfusion-2021.html

Which discusses how you can add a JVM argument to cf that reverts the behavior. You do NOT need to download the offered jar, if you are beyond update 1 of cf2021 (but you DO still need to add the jvm argument to revert the behavior). 

For much more on the issue, including details on the alternative of searching for your code you could change to address the problem (rather than or in addition to using the jvm arg), see my blog post linked to there. 

[Faizan278243197lsr]

Thanks Charlie for your response.

For your information I am already using update 4 of cf2021 but again I have configured .jar file and updated as per recomended in  URL https://helpx.adobe.com/coldfusion/kb/dateformat-function-coldfusion-2021.html

Still issue is same, it's not resolved.

[Charlie Arehart]

As I said, "You do NOT need to download the offered jar, if you are beyond update 1 of cf2021 (but you DO still need to add the jvm argument to revert the behavior".

So take out that jar you added. And did you add the jvm arg? See my post for more. 

[faizank94658980]

Provide me full URL to understand jvm argument. I will try that way. Thanks again in advance. 

[Charlie Arehart]

It's step "2" of the technote whose link you quoted.

As for my post, it's linked to from the top of that page, but you don't need to read that to see what to do. 

[faizank94658980]

Yes, this step also I have done. In fact it was by default true.

Dcoldfusion.datemask.useDasdayofmonth=true

[BKBK]

Yes, this step also I have done. In fact it was by default true.

Dcoldfusion.datemask.useDasdayofmonth=true

By @faizank94658980

Just to be sure, the first character is (-):

-Dcoldfusion.datemask.useDasdayofmonth=true

[Charlie Arehart]

Yes, the cf technote was unclear on the need of that - before any jvm args of that sort. Good call, BKBK. I'd missed Faizan's last reply until now and was about to propose the same.

But that's when on rereading the original post, I came to realize that I was leading Faizan down the wrong road all along. I've offered a new reply with a very different take on (and solutions for) the issue, as it seems to me to be. 

[BKBK]

Hi @Faizan278243197lsr ,

The problem occurs because your code is, strictly speaking, not accurate. The first argument of the LSDateFormat function should be a date-time object. However, you are using a string instead (namely '01/03/2023'). ColdFusion, being weakly-typed, is then free to cast the string to whatever date object it sees fit.

To get an accurate date every time, use something like

<!--- A date-time object --->
<cfset dt=createdate(2023,3,1)>

<cfset actualdt=lsdateformat(dt,'dd-mmm-yyyy')>

<cfdump var="#actualdt#"><br>

[Charlie Arehart]

While this is a reasonable observation, I don't think it would solve Faizan's original problem. In re-reading the original post, I see now that I'd missed the real problem, which to me seems to be about locales. See my new reply, and BKBJ let us know if you may agree that that would show that changing to createdate could have suffered the same dilemma for Faizan's current locale setup. 

[BKBK]

While this is a reasonable observation, I don't think it would solve Faizan's original problem. In re-reading the original post, I see now that I'd missed the real problem, which to me seems to be about locales. See my new reply, and BKBJ let us know if you may agree that that would show that changing to createdate could have suffered the same dilemma for Faizan's current locale setup. 

By @Charlie Arehart

Using createdate would certainly solve Faizan's problem. The resulting date-time object would then remain the same, regardless of the locale.

See for yourself:

<cfset dt=createdate(2023,3,1)>

<cfloop list="English (US),English (UK),Dutch (Standard),French (Standard),German (Standard),ar_AE" item="locale">
	<cfset setLocale(locale)>
	<cfset actualdt=lsdateformat(dt,'dd-mmm-yyyy')>

	<cfoutput>Locale=#getLocale()# : #actualdt#</cfoutput> <br>
</cfloop>

[Charlie Arehart]

Ok, I should have said "would not seem to solve the problem as easily as changing the locale".

If he has only one template doing such date/time processing, your approach certainly WOULD work. But if he has a boatload of existing code and hundreds of such date processing statements, wouldn't addressing the locale be at least easie

? 🙂

It may be the more effective solution also, as a problem with an unexpected locale value could impact more than just date/time processing.

So it seems this strategic approach (setting the right locale) may at least be worth considering in a situation like this, rather than merely a tactical one like changing to use createdate. 

[Faizan278243197lsr]

Thanks BKBK for your guidence.

I have mentioned date that is hardcoaded to make you understatand but date value I am fetching dynamically in dd/mm/yyyy from .cfm file.

argument.from_date is 01/03/2023 in (dd/mm/yyyy) format

<cfset actualdt=lsdateformat('#argument.from_date#','dd-mmm-yyyy')>

<cfdump var="#actualdt#">

So in this senario how I can implimnet your suggested code?

 <cfset  dt=createdate(#argument.from_date#)>

<cfset actualdt=lsdateformat(dt,'dd-mmm-yyyy')>

<cfdump var="#actualdt#">

[BKBK · Accepted solution]

I have mentioned date that is hardcoaded to make you understatand but date value I am fetching dynamically in dd/mm/yyyy from .cfm file.

argument.from_date is 01/03/2023 in (dd/mm/yyyy) format

...

So in this senario how I can implimnet your suggested code?

By @Faizan278243197lsr

Do you mean arguments.from_date?

In any case, here is the answer to your question:

<cfset yearFromDate=listLast(argument.from_date, "/")>
<cfset monthFromDate=listGetAt(argument.from_date, 2, "/")>
<cfset dayFromDate=listFirst(argument.from_date, "/")>
<cfset dt=createdate(yearFromDate,monthFromDate,dayFromDate)>
<cfset actualdt=lsdateformat(dt,'dd-mmm-yyyy')>

[Charlie Arehart]

Faizan, before you undertake this potentially arduous code change (if you need it in more than one place), can you please confirm if you are noticing the other option I offered, as a separate answer here? It seems it could be a far simpler solution.

I'm NOT making any assertion that either is BETTER. so I'm not pressing this to be contentious. As always, just trying to help. 

[BKBK]

@Faizan278243197lsr , In spite of my suggestions, I would recommend that you take a good look at Charlie's suggestion. That is, make sure the locale is configured correctly.

[Faizan278243197lsr]

Great!! it's perfectly working. Thanks a lot BKBK and Charlie to make solve my issue.

[Charlie Arehart]

Glad to hear you solved it...but which was the solution for you? And if one of the answers here, please mark it as the answer. 

[Faizan278243197lsr]

This is the solution:

<cfset yearFromDate=listLast(argument.from_date, "/")>

<cfset monthFromDate=listGetAt(argument.from_date, 2, "/")>

<cfset dayFromDate=listFirst(argument.from_date, "/")>

<cfset dt=createdate(yearFromDate,monthFromDate,dayFromDate)>

<cfset actualdt=lsdateformat(dt,'dd-mmm-yyyy')>

[Charlie Arehart]

Ok, and is it that you only have one such date reference in all your code base? If so, lucky you. 🙂

Or maybe you're oniy focused on solving some single blocking request, without concern about the rest of your code base. 

I just am so surprised you've made no mentioning of even considering the locale matter I offered as being both the root cause problem and solution. 

I don't press this so much to trumpet that solution as to make sure you've at least considered it--especially since someday someone else may see this thread and be drawn to that tactical change (createdate) vs the strategic one (set the correct locale at the app or server level). 

[Charlie Arehart]

Agh, I'm so sorry. I am seeing now that my first reply on all this last weekwas solving a different problem than you were having. Your issue is NOT about the d vs D issue (you're not using D, after all).

Instead, your issue was clearly about whether mm-dd vs dd-mm. And that's a LOCALE issue.

For instance, you could modify the lsdateformat function to name a locale that WOULD treat a date as dd-mm, such as this:

<cfset actualdt=lsdateformat('01/03/2023','dd-mmm-yyyy')>

<cfdump var="#actualdt#">

That should get you the date you want. But that would be annoying to change in all your code.

Instead, it's that CF (or the JVM or the OS where CF is running) is of a locale that treats dates as mm-dd.

You can call the cf getlocale() function to see what it returns. And what would you have expected? I suspect they're not the same. 🙂 

And you can set the locale at the application level with the cfml setlocale() function, or at the jvm level with the -Duser.language and - Duser.region jvm args. For more on those, and valid values, see a discussion such as https://stackoverflow.com/questions/8809098/how-do-i-set-the-default-locale-in-the-jvm.

And as that notes, again it could be a setting in the OS where CF is installed that is controlling this locale so that if you change it there then the jvm (and cf) would honor that (unless you overrode them using any of the above).

Let us know if this gets you going.