I have a component which can save a lot of time for many date formats
Using it once to handle dates in dmy sequence and again for dates in mdy sequence, and finally merging the two outputs can get the results quite quickly and with minimal config requirements
Provided there are no superfluous extra characters, it simply needs to be told in what order date month and year will appear, and it does the rest:
It has a choice of two locales. I use en-US as primary and en-GB as secondary as this then allows it to differentiate both Sep and Sept. The other locale-specific “gotcha” is in the case of AM/PM or am/pm. Again this just gets handled. It’ll happily accept Am too. This would cause problems in the standard date node.
Example - each component returns the set of dates that it can match to its defined dmy sequence:
Example outputs after merging the two lists
This in my view is how KNIME’s date parser ought to work. Within reason, why should we need to state the exact format, when it can be inferred from a quick hint,
e.g. here are a variety of date strings:
Here’s a demo :
The above component was based on some ideas from back in 2021, when I first starting using KNIME, which may be of interest. The component doesn’t have ALL the features mentioned in this article (it doesn’t handle “January 1st” for example. I lost a few nice-to-have features in the interests of simplicity. 