I have a variable that inputs in a DDMMM format. It hasn't been an issue to do a datetimeparse, except we've encountered an issue with 29FEB. Without including a 2024 (and modifying the format it is expecting, obviously) it won't parse it seemingly because it defaults to the current year if not specified. In my case, it would be ideal to assume the year of the soonest date, meaning 01OCT would be 01OCT23, 02JAN would be 02JAN24. I can see how that would be problematic in other cases though, so I'm not sure a functionality change is the play here.
Since I don't have a year on my variable. Any ideas on how to get around this?
Hey @Kevin_Roberts ,
Kind of a roundabout way, but maybe this will work. Let's see if the engineers can come up with a more elegant solution
{variable="29FEB"}
{year1={time: YY; shift=+1Y}}
{date0=catch(datetimeparse(variable, "DDMMM"), datetimeparse({time: DDMMM;shift=-1D}, "DDMMM"))}
{if: datetimediff({time: YYYY-MM-DD}, date0, "D")<0}{=datetimeparse(variable&year1, "DDMMMYY")}{else}{=date0}{endif}
- I'm checking if the parsed date is in the past, and if it is I parse it with next year.
- I also catch if there's an error in parsing and if there is, I set the parsed date to be yesterday, so it will parse it again with next year (based on the previous rule)
Is that what you had in mind?
Thank you Dan, I did finally get this working. Now that I'm aware of this, I can start building new snippets correctly.
Longer term, I wonder if there'd be a way to have the datetimeparse have a field to toggle to say, future, past, or current. Then based on those choices it could update accordingly.
Short term, perhaps a warning or note could be added to the documentation page (Text Blaze | Formula Reference) to indicate it defaults to current year if you don't specify/force it. So other folks can avoid it in the future. I imagine it may become a bigger issue toward the end of 2023 as the dreaded 29FEB becomes more of a likely input date.