TLDR; 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 will 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 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. It also applies to lsdateformat, and any functions or tags that take a date mask, such as dateadd, datecompare, dateformat, datediff, dateformat, datepart, datetimeformat, parsedatetime.
So yeah, this seems a huge deal!
What changed, why is this a problem, and what can you or Adobe do? what about Lucee?
What's changed is that a new dateformat mask of D was added (to mean "day in year"). Of course, the lower-case d mask has long existed and meant of course "day in month", as in dateformat(now),"m/d/yyyy".
The problem is that it turns out CF was loose in its enforcement of this casing before, so you got the same "day in the month" with a "d" OR a "D", such as M/D/YYYY. Until CF2021, that is. So what now?
For more, read on where I discuss what you can do, what Adobe might want to consider, and how the same "loose casing" of masks happens in Lucee as well (but Lucee has no D for "day in year", so does not have the "same" problem, yet). I also explain how this D for "day in year" is indeed a Java-standard mask value.