Due to recent updates, all users are required to create an Altair One account to login to the RapidMiner community. Click the Register button to create your account using the same email that you have previously used to login to the RapidMiner community. This will ensure that any previously created content will be synced to your Altair One account. Once you login, you will be asked to provide a username that identifies you to other Community users. Email us at Community with questions.

Changes on date conversion functions

raulsamaniegoraulsamaniego Member Posts: 9 Contributor II
in Help
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

Best Answers

  • jwpfaujwpfau Employee, Member Posts: 303 RM Engineering
    Solution Accepted
    Hi,

    Thank you for your feedback.

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

    Greetings,
    Jonas
  • Marco_BoeckMarco_Boeck Administrator, Moderator, Employee, Member, University Professor Posts: 1,996 RM Engineering
    Solution Accepted
    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_BoeckMarco_Boeck Administrator, Moderator, Employee, Member, University Professor Posts: 1,996 RM Engineering
    edited February 2023 Solution Accepted
    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

Answers

  • raulsamaniegoraulsamaniego Member Posts: 9 Contributor II
    Works OK!
    Thank you very much, Jonas.

  • raulsamaniegoraulsamaniego Member Posts: 9 Contributor II
    Hi Marco,
    Thank you very much. I understand the reasons about the update but I think it would be nice to help the users about the possible workarounds. 
    As I told you, It was impossible to find information about it.
    By the way, note the old function is still running in other operators.
    Regards
    Raúl
     
Sign In or Register to comment.