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.

It turns out that with the release of CF2021, Adobe introduced a breaking change...if you use any of the CF tags or functions that use date formatting masks. The problem is that while a capital "D" value used in such mask used to simply mean the same as a lower-case "d" ("day of month"), the change in CF2021 is that "D" now means instead "day of YEAR"! That can be a devastating problem that might lurk for days or weeks, corrupting your data.

TLDR; You have two solutions:

• you can choose either find and change the affected code (not easy but using techniques shared below)
• or you can implement a new JVM arg that Adobe offers to revert this behavior back to how things worked before CF2021 (discussed below), which still applies in CF2023 and beyond

If you're affected, you must do one or the other of these things. For more, read on.

The sections below include:

• The new JVM argument, and how to implement it...carefully
• What changed, why is this a problem? (with examples)
• This change affects more than just the dateformat function
• Finding the code, to change it instead
• How were we to know?

The new JVM argument, and how to implement it...carefully

Adobe solved this problem by offering the option to use a new JVM argument to revert this change of behavior:

You can add that (carefully) either of two ways.

Adding it using the CF Admin

One way to implement that change is to use the CF Admin's "java and jvm" page, to edit its "java arguments" field, where you could just add it at the end of what's already there separating it with a space from what's there (do NOT put it on its own new line). If you do that, you will be told you must restart CF for that to take effect. If CF does not start, see the next section.

Adding it to CF's jvm.config file

The other option to add that arg is to instead edit CF's jvm.config file (found in CF's cfusion/bin folder, or [instancename]/bin if you run multiple instances). Before changing it, you would be wise to save a copy of it.

(And note that changes made on that CF Admin page above are actually saved into that file for you. If you make a mistake there and CF won't start, then you will HAVE to edit the jvm.config file to correct your mistake.)

Edit the file and find its java.args line (if it has a # in front of it, that version of the line is a commented-out one). Again, add the new arg above to the end of whatever is on that line--separating it from any other args with a space and being careful NOT to put it on its own new line. Save the file but keep it open.

Then restart CF. Since CF won't start if you make any mistake, review the change you made, or consider using your editor's undo feature, or revert to the file backup I recommended you make.

You should now find that your use of D in date format functions again means "day of month".

When the JVM arg was introduced

FWIW, Adobe first added this via a special hotfix in Dec 2020, as I blogged about then, a week after this original post. That had offered a special hotfix jar which enabled the ability to set that JVM arg.

Then CF2021 Update 1 made the JVM argument option a permanently available one. Again, it's still needed (and still works) in CF2023 and later.

(To be clear, Adobe never did NOT revert the behavior for you: you must use this JVM arg to do it--again even in later CF versions--or you can choose to try the other option of trying to find the code that needs to change, as discussed below.)

What changed, why is this a problem? (with examples)

Let's start with just a simple demo of the problem. Consider this fragment, which could exist in similar form in millions of CFML templates: 

See anything wrong? Probably not. It would indeed "work fine" in CF2018 and before, producing 11-24-2020, as most would expect.

But that same code in CF2021 will produces instead 11-329-2020, which virtually no one would expect! Because again D now means "day in year". It's a Java-standard datemask, but until now CF didn't complain if you used D. It treated it like d.

And the disaster is that you may have old code that's worked like this for years, but now in CF2021 that code will produce these WRONG RESULTS, which is bad enough if it's just a date shown on a page; but it's catastrophic if that date is then used in code to make decisions, to perform calculations, to store in databases, to pass to other systems, and so on.

And of course it applies if you use 2 D's, as in MM/DD/YYYY, or any variation like DD-MM-YY, and so on.

This change affects more than just the dateformat function

Note also that this issue applies not only to dateformat but several related CFML functions with "date formatting": not only lsdateformat (locale-specific dateformatting) but also any of many functions which TAKE a date mask, such as dateadd, datecompare, dateformat, datediff, dateformat, datepart, datetimeformat, parsedatetime. And there are also tags that accepts a date mask, like cfinput or cfgridcolumn which both have a mask attribute.

So yeah, this is a huge deal for some.

A "live" example you can run

Here's a running example, first at cffiddle.org, where you can change the version to run it either as CF2021, CF2018, or CF2016.

Here also is a link to run the same code at trycf.com.

Finding the code, to change it instead

So, that's the problem. And if you don't want want to rely on that new JVM arg, you might want to instead look for and change the affected code. That's not so easy as it may seem at first.

There are of course ways to use either editors or command line tools or search tools to search for any string in code (my favorite, for Windows, is File Locator Lite), and they can all be told to do a case-sensitive search.

But a challenge here is that there are so many mask variants you may have, such as M-D-Y, MM-DD-YY, MM/DD/YY, DD/MM/YY, and so on, not to mention those multiple functions that are affected. It would be impossible to pick any single normal string to be sure to find ALL such occurrences.

But here's great news: since posting this blog entry, some kind community contributors have come to the rescue (in the comments below) with regular expressions that you could use in any of various editors, to find and replace these troublesome dateformat usages.

In particular, see comments below, 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!

So with those two solutions covered, let me continue with some of the original content I'd written.

How were we to know?

Sadly, this change was not mentioned in the 500-page beta release notes, nor was it on the what's new page, both of which I discussed in my blog post on, "The many new and improved features in CF2021".

I only found this issue yesterday myself while working with a client, helping him find and understand what was going on, and how things were unexpectedly different.

And while the new mask value of D is indeed documented in the CFML Dateformat reference, it's NOT (currently) indicated there as being something new (this was eventually corrected, indeed with it pointing to this very post of mine). 

I did a comparison with old versions of the docs to discern that it was indeed new. (There's also a new M and Y value, but I have not been able to tell how they differ in their results from the older m and y.)

The Java standard dateformat also supports "D" vs "d"

FWIW, I will note also that the use of the D for "day in year" is not something Adobe just "created out of thin air". It's been in the Java dateformat for years, both per the Java 5 docs (2004 timeframe). 

Again, the problem is not so much Adobe supporting such a "standard" dateformat mask--it's that until now, CF ignored the case and so folks have current apps that use "D" but mean (and found that CF acted as if they meant) merely "d". A HUGE difference (which perhaps Java never suffered if back in earlier versions they had not blithely allowed a "D" where only "d" was defined, if there was such a time).

What about Lucee?

For those who may wonder, I'll note that Lucee works the same as CF did BEFORE 2021--it DOES allow and treat "D" the same as "d".  And according to the Lucee docs for dateformat, it has no current mask for "day in year".  

I'll note also that it too makes no mention of how case is ignored (and none of the masks are capitalized).  So whether we can say "Lucee handles things better" seems an open question, but at least they can learn from this debacle and should NOT implement support for a "D", given how they also were loose in allowing a "D" to be left to mean the same as "d".

Finally, if it may interest anyone, here is a gist to run against Lucee the same code from the cffiddle above, using trycf.com.

Conclusion

For more content like this from Charlie Arehart:

• Signup to get his blog posts by email:
• Follow his blog RSS feed
• View the rest of his blog posts
• View his blog posts on the Adobe CF portal

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