Add an optional second output port for rows fail conversion
With the String to Date&Time node, if the option to fail on error is deselected, any rows that could not be converted using the supplied format mask have the output set to null.
I can think of many instances where the next thing I’d want to do is see which rows failed, so often I’d then add a row splitter to split them out.
A useful addition to the node could be the addition of an optional second output port, with a configuration setting to split failed rows to the second port. In this way we then (optionally) have all the “good” dates separated from the bad ones for further analysis or maybe for sending to a second String to Date&Time node configured with an alternative format mask.
Ability to make date matching case-insensitive
I’m just going to leave this link here, because I think that this really ought to be an exposed option given that the option is there in the underlying java classes.
I’m bringing these up now because I think the String to Date&Time node is likely to be heading for its MUI makeover, so perhaps these can be considered at the same time?
I wonder if a better answer to this question would be to add multiple alternative format conversion solutions? For example, if the first one fails, try the second one, if the second one fails, try the third one, if the third one fails, mark it…
Actually, it should be very simple to implement in the code, just try...try...try
Just a quick idea… In addition, I think takbb’s idea is good, haha
I’m bringing these up now because I think the String to Date&Time node is likely to be heading for its MUI makeover, so perhaps these can be considered at the same time?
Yes I agree, being able to enter a clear sequential list of formats to try would be useful in its present form which is pretty much what the inner workings of my Parse Date&Time component does, although the user doesn’t see it.
But… should we really require the user to specify format masks, though, for 99% of date conversion tasks?
I believe a tool like KNIME should remove the complexity where it can so it can be used by anybody, and the component mentioned in the above link demonstrates that for many (possibly all?) common use cases simply knowing the order DMY, MDY, YMD or YDM of the Date (even with both numeric and textual month names intermixed), should be sufficient for some kind of “simple mode” without the user having to write format masks that are really there to only to describe which specific delimiters are used.
For the remaining obscure formats that would almost never occur in common data processing there could still be an “expert mode” to find fine control of the masks if really necessary.
