Forum Discussion
@del - did you check to ensure it was the right century? The parse works but I think the year is wrong.
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: