I’ve just updated to Knime v.4.5 and I got a parse error with a workflow that I had run hundreds of times before the update (without any error). The format of the dates and times I want o parse is:
30/08/2021 06:32:54 PM
As format to parse I am using:
dd/MM/yyyy hh:mm:ss a
When attempting to run, I get the message “Execute failed: Failed to parse date…” with the string that I showed before.
Community, any ideas to what to check or fix?
Hi @christiam,
I assume this problem occured with the String to Date&Time Node? You’re right, from how I understand the format specifiers this should indeed work (but it doesn’t).
However, I was able to get the node to work by changing the locale from de-AT to en-US. I hope that gets you back online until someone from the team can comment on this.
Happy New Year, T
String to Date&Time – Node Documentation
DateTimeFormatter (Java Platform SE 8 ) (oracle.com)
Hi @christiam and @Thyme, this is an issue that came about with the move to a later version of java as the date handling changed from what it used to be (in the java 8 documentation that you have referenced).
@christiam… Did you upgrade from knime 4.3 or 4.4? I think it was probably from KNIME 4.3 as I believe your data would have worked with that version, but not with 4.4 and above.
This was a change in the underlying java date handling and not a direct change in knime. For some locales, the AM/PM now has to be in lower case instead of upper case for the date conversion to work.
There is a config setting that I have detailed in the following post, which you may find of use of this is causing problems…
Hope that helps, and explains why it doesn’t now always work the way you (and I) previously expected.
Hi @takbb,
I suspected the problem to be caused by a change coming from Java, thanks for confirming that. It doesn’t work with lower case AM/PM though, that’s the first thing I tried. In fact, it has to be upper case, even with the en-US locale. de-AT doesn’t work either way. Still a good reference for future people, thanks.
Hi @Thyme (and @christiam ), As I haven’t previously tried non English based locales, I thought I’d have a look at this.
The java locale changes for AM/PM time handling are now (very) language dependent.
I put together a quick test workflow to see what the expected values are for different locales en-US, en-GB, de-AT
As you have already indicated, en-US remains with upper case AM/PM, so I used that to convert the sample date/times into a datetime column, and then tried converting back using each of these three locales.
This is the result:
As can be seen, the en-US remains as AM/PM, en-GB has changed case to am/pm, and de-AT uses nachm./vorm.
Date time format change.knwf (13.0 KB)
The compatibility setting mentioned in the previously referenced post should cause java (and therefore KNIME) to behave the old way, but as you have found, using the locale of en-US is also a way forward (and probably the better way forward), if the time format matches that particular locale. I would suggest only use the compatibility setting if you have a large number of workflows that now fail, and/or you don’t ever receive data that is generated using the new locale formats.
Note
If you run KNIME with the compatibility setting in the KNIME.INI file…
… all three locales will require and generate the same AM/PM in the attached workflow:
e.g.
Going one step further (or back?) to verify the solution is quite smart! Shows how to solve the same issue for the hundreds of other Locales.
Since those changes potentially add confusion to the already mind-boggling problem of timezones and DSTs, my advice is to use ISO formatted UTC timestamps whenever possible (generally, not only here). No timezones, no daylight savings, no problems. At least until you have to display that to the user 
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
