Ternary operation to handle diff date formats

[UrsVinny]

The source file contains Reporting Period value in diff date format.
Aug-2022
Aug-22
AUG 2022
August-2022
I am using the below ternary expression to handle the above mentioned date pattern.
isNaN(Date.parse($RPT_MONTH,‘MMM-yyyy’)) || isNaN(Date.parse($RPT_MONTH,‘MMM-yy’)) ? $RPT_MONTH : Date.parse($RPT_MONTH,‘MMM-yy’).toLocaleDateString({“format”:“MMM yyyy”})

But when the value is in August-2022 the above code is not converting it into AUG 2022

Any kind of help will be highly appreciated.

Cheers
Vinny

[koryknick]

@del - did you check to ensure it was the right century? The parse works but I think the year is wrong.

[del]

@koryknick,

The century is a good call-out and something to consider for the case. I did consider the century and I’m leaving the century of the two-digit year to be determined by the Date.parse() interpreter as I don’t know the actual use case, the source data, or full requirements of whether it is intended to be historical or future/predictive reporting.

In any case, the “$2” replace output (of the above) could be replaced by a hard-coded “20” value or other round-of-century logic calculation if the date is always future dated and Date.parse() picks incorrectly for certain scenarios. My testing shows Date.parse() chooses the current century for around 19 years added (41 converts to 2041) and then backdates a century about 20 years added (42 converts to 1942).

Meanwhile, I shortened the regex further with current 2-digit logic - producing the same results as the others . (Like I said - regex is Play Doh)

Date.parse($RPT_MONTH.replace(/^(.{3})[^\d]*(\d{2,4})$/,"$1-$2"),'MMM-yy') .toLocaleDateString({"format":"MMM yyyy"})

(☝️ 40-minute later edit to code snippet to remove inserted hard-coded value)

Here’s some testing output:

[koryknick]

Great solution. Love the regex usage. Thanks for the response to my query!

[del]

First thing I did this morning was reviewed my proposed solution. This solution is feasible for narrow windows of time, which would be the assumption required to use it. However, there is a caveat on the century concern, which Kory brought up first, which is that if we’re reading a large window of time (for instance, say we’re trending inflation since WWII {I know, an extreme case, but makes the point}), then looking at “AUG-42” today using Date.parse() would result in “1942”, but if we process the exact same dataset this time next year, it will result as “2042” due to Date.parse() behavior around 19 vs. 20 years out. Very unreliable in that way.

So, use with caution.

Soapbox warning… I can’t figure out how we rounded Y2K and still have datasets that have 2-digit year representations. In my opinion, this should be fixed at the data source, where it is broken, and not rely upon fuzzy logic to try and figure it out by best guess. While solutioning this, I would have so many questions and caveats with which to annoy the requesting stakeholders.

[UrsVinny]

@koryknick
Sorry for responding so late…I was able to fix the issue using ternary operator but nevertheless usage of regex is more kool than Ternary operator.

Thanks once again to each and every one.