[Looking for Charlie's main web site?]

Hotfix released for CF2021 date-mask compatibility issue

Note: This blog post is from 2020. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Good news to share: if you're concerned about being impacted by a pressing compatibility issue in ColdFusion 2021 (regarding using "D" in a dateformat mask), Adobe released a fix for the problem last week. There are 3 simple steps to implementing that fix, one of which is a JVM arg change to that YOU MUST MAKE--even with the "fix" in place--if you want to revert the behavior.

Or you can change your CFML code to get around the problem, as I also discuss below.

[Update: As of Mar 2021, Adobe now offers this "hotfix" as of CF2021 Update 1. You still need to add the JVM arg discussed, if you want to do that:


Again, while no longer need to obtain and implement the hotfix jar file itself, the update does NOT change the DEFAULT behavior, which is why that JVM arg is still necessary. The rest of the information below applies.]

Read on for additional details.


Two weeks ago, I shared that other blog post reporting a problem discovered with CF2021, where a new Dateformat mask of D had been added, for "day of year" (for the dateformat and lsdateformat functions, perhaps among others.)

That would be fine, except that CF had traditionally not paid attention to the case of datemask values. So with this change, existing code that might refer, for example, to a dateformat mask of "MM-DD-YYYY" would produce today a date of "12-342-2020". With the fix implemented, the mask would produce instead a date (today) of 12-07-2020.

Of course, another way to get the "correct" date would be to change the dateformat mask to use a lowercase d, as in "mm-dd-yyyy".

Implementing the hotfix

[Update Mar 2021: As of the release of CF2021 update 1, in Mar 2021, you no longer need the "special hotfix jar" discussed in this section. That's rolled into Update 1 and above. But you DO still need to add the JVM arg, if you want to tell CF to revert its behavior of the D dateformat arg to how it worked before CF2021. The CF update does NOT revert the behavior for you. Proceed with point 3 below.]

There are three relatively simple steps to cause this new/corrected behavior, as documented in the aforementioned Adobe technote:

  1. Download the hotfix jar. (This step and the next one will likely not be needed once the first formal CF2021 "update" comes out. Indeed, this link may fail to work soon after that first formal CF2021 update, in which case just skip here to step 3.) Again, this is now no longer needed after update 1 of CF2021.)
  2. Place this jar file into the cfusion/lib/updates folder within CF2021.
  3. Add the following JVM argument to CF's jvm arguments:
    whether by editing those in the CF Admin "Java & JVM" page, or edit the jvm.config, found in the cfusion/bin folder within CF2021. (The latter option is safer, as you can more easily save a backup of the file and revert it, if you make any mistake.)

If you have created another instance, using the Instance Manager feature in the CF Admin in the Enterprise, Trial, or Developer edition, you would need to repeat those steps for that instance, with regard to its own folder as a sibling to cfusion, as well as its own CF Admin.

Finally, I mentioned above that the jar will not likely need to be updated once the first real "update" to CF2021 comes out. Similarly, it's likely that the update would also remove that jar file, so you need not to bother. I discuss this matter of applying such "special hotfixes" in this blog post.

Is there any way to easily change all my code instead?

Some readers may either be unable to implement this fix, and/or change their JVM args, or for some other reason may rather fix their code (to change their use of D to d) rather than rely on this Adobe "fix".

I will point out that in the comments to my previous post on the matter, there were a few commenters who offered regular expressions that you could use in any of various editors, to find and replace these troublesome dateformat usages. In particular, see comments there first from Scott Steinbeck and then from Curtis Fraser, as well as the couple of comments before and after each that relate to the use of such regex's in different IDEs/editors. Thanks, guys!

What if I DO want to use "D" for "day of year"

Of course, if you ever DO want to use D as "day of year", you'd want to either remove that JVM argument or set its value to "false".

Just know then that you must then be sure to find and correct any references to "D" in dateformat masks which you really mean to mean to return "day of month". See the previous section.


Great to see Adobe respond to this issue so quickly.

And while we can lament that they didn't anticipate this issue previously, see my first post for a couple of points to keep in mind in that regard: first, the "D" value is a long-valid Java date mask for "day of year" (which CF was only finally implementing), and second, Lucee has the same "problem" of currently ignoring the case of dateformat masks (so that they'd have the same issue if they ever tried to implement this "D" mask value.

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Hi Charlie. I went the former route by applying the jvm argument update in the Administrator itself (rather than within the jvm.config file). If I'm looking at things correctly in the file system, CF Admin made a backup of (jvm.bak) upon applying this config change in the admin. Can you confirm?
Andy, yes, the cf admin always makes backup of the file as well, but my point in suggesting the alternative of editing and backing up the file was that:

a) a typical user of the cf admin would not readily know what and where these files are

b) so if they made a mistake that would keep cf from coming up, they'd not be able get to the admin to see/revert their mistake

c) also, the backup the admin makes is one that gets overridden by a subsequent update. By making their own backup, one would likely choose a different name that would not get lost by that automated backup

Still, I appreciate your checking in for more clarity. Hope that's helpful.
Hi Charlie, just upgraded from 2018 to 2023 and this was a life-saver!
# Posted By Paul Durrant | 8/25/23 10:50 AM
Thanks Paul. Yep, this problem (and solution) will remain significant for years to come, as people transition to cf2021 or later from any previous version.

Fwiw, I also have a preso I migrating to cf2021, which would benefit folks moving to 2023 (or beyond) as well, at carehart.org/presentations.
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting