Changes on date conversion functions

Question

Hi,

Recently updated from RM Studio 10.0.000.to 10.1.001.

I need to convert strings like "20230207" (year+month+day) to simple dates.

This expresion worked on old Generate attributes operator:

date_parse_custom("20230107",yyyyMMdd")

Returning dates with 12:00:00 AM  CET time wich are ok, but this function disappeared in new version and I can't find much documentation to move it to new date_parse_str()

Ane help welcome.

Thanks in advance

jwpfau · Accepted Answer

Hi,

Thank you for your feedback.

As a workaround you could try to add the missing informationdate_parse_str(concat(date, "0000CET"), "yyyyMMddHHmmVV", "us")

Greetings,
Jonas

Marco_Boeck · Accepted Answer

Hi,
The point of the change was that "date" only is a bit of a weird concept once you start taking timezones into account. Feb 08 in Berlin, Germany as a point in time is not necessarily Feb 08 in Sidney, Australia. Dates always had an implicit time component included (usually midnight local time), so if you were collaborating with colleagues across different timezones, dates could be deceiving. Subtle errors were sometimes introduced because suddenly the date could mean a different day in another timezone on another computer and stuff like that.
Therefore we decided to enforce the inclusion of a time and a timezone to avoid this. We now offer "date_time" and "time of day" as two distinct concepts, but no longer just date. This was done to make sure all calculations will be correct, no matter which local timezone the machine running a process is in.

We see that there are a few cases where you'd want to calculate say number of days between 2 dates which is now a bit more complicated, but again, same problems as listed above would apply if we did not force inclusion of a time + timezone. We decided in favor of explicit definitions and correct results, and made it a bit more complicated as a tradeoff.
Regards,Marco

Marco_Boeck · Accepted Answer

Hi,

Yes, thank you for your feedback, we will look into how to make that more user-friendly / obvious what is required. I agree, it's not handled as nice as it could be right now.

As a sidenote, we are always rolling out changes like this in a rolling manner, meaning that we change not necessarily all operators at once. So now we have some other operators that still use the previous expression parser.
And in all cases, existing processes will continue to work because we keep both versions operator you get when dragging it into a process, but the previous, existing version still exists to keep existing processes intact.

Regards,
Marco