I realized today that the current STRING TO DATE/TIME node does not function as well as the STRING TO DATE/TIME (LEGACY) node and that forces me to use the old node. I was hoping Knime could bring the new node up to match the old functionality.
I have a CREATEDATE column that is in a string. The date column uses 1 or two character month and day as the date demands. For example two rows values might be 2/1/2022 and 11/12/2021. The old STRING TO DATE/TIME (LEGACY) node will accept a format of MM/dd/yyyy and will successfully convert both of those rows.
However the new STRING TO DATE/TIME fails. It requires a M/d/yyy format for the first date and MM/dd/yyyy for the second. Basically I would have to split the rows based on length into all the possible formats.
Like I said I’ve fallen back to the old legacy node and I don’t like that because it only works on one column at a tmie and I have many date columns I need to convert. So I’d prefer to use the new node which accepts a list of columns to include but I really need it to match the legacy nodes compatibility.
1/1/2022 would match M/d/yyyy
01/01/2022 would match MM/dd/yyyy
For Month values already in double digits, that is anything > 9, both M and MM are acceptable, and similarly with Day.
For example 11/11/2022 would match both M/d/yyyy and MM/dd/yyyy.
So, in your case, you should use M/d/yyy which will match both 2/1/2022 and 11/12/2021. That is of course if the Month and Day are in the correct position (any value beyond 12 would usually tells us which position is month and which position is day).
EDIT: FYI, while the LEGACY node behaved differently, this current behaviour is the correct one as it’s what the standard is, or at least all programming languages that I know follow this convention, and that for years. So it’s better to update your workflow since it’s most probably that this is the behaviour will stay rather than what the LEGACY node is allowing you to do (which will be deprecated).
