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.
