Dates not formatting correctly since update to CF 2023 (found solution)

[kirkdickinson]

My CF host just did a server update to CF 2023. I spent all day fixing scope issues, but that wasn't too hard.

I noticed that my pages are showing weird dates. For instance in the MySQL database, this date shows as: 2023-05-15 00:00:00, But it displays as: 5/135/2023

The code to display that date is #DateFormat(Born,("M/D/YYYY"))#

Figured out what the issue was... D is days from the first of the year and d is days fo the month. When did this change?

[Dave Watts]

I think it's always been this way. The metacharacters (d, m, y) have always had different meanings when capitalized. However, I guess it's possible that some database drivers didn't honor those meanings. Anyway, look at the docs for dateFormat and LSDateFormat in the CF documentation.

[Charlie Arehart · Accepted solution]

The change regarding D meaning day of year in dateFormat functions was introduced (unexpectedly) in cf2021. So you must be migrating from cf2018 or earlier. Some good news: Adobe offered a JVM arg that would switch it back to ignoring the case of that "d". See the cf docs on the dateFormat function. 

Or yes, you can change your code. I did a blog post the week this was introduced, and it some folks shared regex search strings for different major editors, to help there. I also offer the jvm arg and how to apply it as well as more on the change :

https://www.carehart.org/blog/2020/11/24/breaking_change_in_cf2021_dateformat_D_vs_d

As for your work to change scopes, I'll point out that while it's good to be done, you could have avoided it. This was a change introduced to both cf2023 AND cf2021 last march. More in a couple of blog posts that may help you:

https://www.carehart.org/blog/2024/3/12/cf_updates_march_2024_possible_breaking_change

https://www.carehart.org/blog/2024/7/18/dont_miss_helpful_feature_identify_implicit_scopes

And as long as you're migrating beware of another important breaking change introduced in an update last June. I have posts on that there as well, from June and July. See the calendar offered in my blog site. 

Finally, if you'd like to stay more up to date on such matters, I do blog about each update (to cf and to Java)--including extra info not offered by Adobe, and you can subscribe to my blog via a simple form offered there.

Let us know if the first point above gets you going. 

[kirkdickinson]

Yeah, my host just updated to the newest version of MySQL and CF 2023 (from 2018). I had source files for all the code locally and was able to do a find replace to fix all the instances that were messed up. The scope is taking a little longer because I have to find where it breaks and fix it. When I had my first CF class ages ago, he did talk about putting FORM. and URL. to scope the variables, but I guess I got lazy and wrote a bunch of code that wasn't scoped. It worked before without doing it so I didn't do it. Another instance where lazyness came back to bite me later. Oh well, it will only take about 8 hours work to get all of them fixed.

Thanks for the links, I will subscribe.

-K

[Charlie Arehart]

Thanks for the clarifications. I'd be surprised, though, that a host would not implement the jvm arg for dateFormat. Otherwise there will indeed be tremendous pain for most of their users on such a cf instance: and it can be devastating in also messing up db data and more. Can you share what host it is?

As for the searchimplicitscopes issue, it's more understandable that hosts may opt not to implement that jvm arg, if they feel the tradeoff of security trumps compatibility. Even so, they should still help people to know that the app-level setting exists, because again the compatibility impact can be very significant for most apps. You're definitely not alone or even in a minority of people who didn't worry about scoping issues, as long as their code "worked". Even people writing code today could easily fall into that...unless their cf instance has this update and have not implemented either of those two mitigations. But even for those who do can use that patch to log the continued "implicit scope" use, as I discuss in the July blog post.

But what doesn't kill us makes us stronger. Keep on with your workout! 🙂 

[kirkdickinson]

Charlie, I am on a shared hosted account at Hostek.com. I have been there for at least 10 years and they have been decent to deal with. I am not much of a CF coder. All of my stuff is just tag based and querys. I did take a beginner CF class at a local junior college years ago when CF was a much more common server platform. Previously, I was on a server that was a part of a local dial-up provider. They had CF, so that is what I used to start my website. When the dial-up died, they sold their company to a bigger company and they discontinued their CF servers. 

I found a budget host based in New Jersey, but when I had problems I soon realized that they only had an address in NJ, but they were actually based in Penjabi. I couldn't ever understand their tech support people and they were very slow responding to tickets. I got on Adobe's website and found their list of CF hosts and started calling them. Hostek answered the phone and the tech support guy had a southern accent. I asked him where he was and he said Oklahoma. Sold. I have been with them ever since. I think their main US data center is in St. Louis now.

[Charlie Arehart]

Thanks, Kirk. I (along with many here) are familiar with Hostek. Some folks might even relay challenges they've had with them in the past year or so: I know that Hostek is trying to address those.

Again, I do think that they and any shared hosting company should at least implement the jvm arg for dateFormat. As I relayed in my Nov 2020 post on the matter, the real shame is that Adobe didn't reverse the behavior--requiring those who WANTED to change what the D meant to have to add the arg. Sadly, they did not, so as I anticipated this problem will affect people for years to come, as they transition from cf2018 or earlier. I suspect as many as a quarter of all cf deployments may still be. Again, yours is not a unique position.