Feedback: Legacy String to Date&Time is more flexible than non-legacy version

I find often that the current iteration of the String to Date&Time node is less flexible and less user friendly than the legacy version. For the current version it seems that rarely does entering a date format outlined by the documentation in the node description actually work.

Additionally, it seems as though the non-legacy version is overly picky, where the legacy version does a much better job of interpreting what the user’s end goal is.

As a quick example, if I have the node set to convert a string as HH:mm:ss.SS – the string must EXACTLY be HH:mm:ss.SS… If the string is HH:mm:ss.S, the node will fail. On the legacy version I can convert the string as HH:mm:ss.SS and it will work no matter if it is .S or .SS… On the legacy version, if I don’t want the fraction of the second, I can format it simply as HH:mm:ss, and it will work. But it will not work on the current version. This might seem like a small complaint, but it is annoying trying to convert strings to Date & Time when you don’t necessarily know how the format will be (e.g. if you’re using an execution time as a variable).

I’ve posted a few questions once before on the String to Date&Time, but thought I would start a topic to give my express feedback in hopes that enhancements to the String to Date&Time node can be added to the next sprint or story.


1 Like

Hi @Snowy,

this kind of feedback is very helpful, thank you for that!
However, I have a few questions to clarify.

Do you have an example for which case the documentation is not right? It’s not written by us but by Oracle and is used by many Java users. The date&time parsing is a very complex thing since there are so many different formats used. That makes the documentation hard as well. It could be that Oracle missed something.

I tried this example with these strings:

  • 12:13:23.11
  • 12:13:23.2

When I use HH:mm:ss.SS with the legacy node, I get

  • 12:13:23.011 and
  • 12:13:23.002
    These results are actually wrong, aren’t they?

I must admit, finding the right format for the non-legacy node is a bit complicated. The trick is to use square brackets for optional fields. I used HH:mm:ss.[SS][S] as format and got

  • 12:13:23.110 and
  • 12:13:23.200

These results look right for me.

Does this help you? It’s true that the new node is sometimes a bit harder to use. The legacy node accepts more actually “wrong” formats and tries to make the best out of it. However, it’s hard to guess what exactly will happen and if the output will be right. That’s why I recommend investing more time in finding the right format for the new node but then the whole parsing process is more transparent. Defining optional sections with square brackets does often the job.



This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.