I must confess to being very surprised by KNIME’s handling of 2 digit years in this regard, as it is a different scheme to Java on which I had assumed it would be based. It is also different to Excel which is similar but subtely different to Java.
Take a look at the table beolw of 2 digit year dates entered in Excel. The second column is Excel’s interpretation of those dates using the Excel formula DATEVALUE()
Processing the first column in KNIME using String to Date&Time gives the third column, and the fourth is using a Java snippet node using a simple Date from String conversion:
The java snippet used the following code to simply build a Date from the String:
As you can see none of the interpretations are exactly the same, I have marked in red where one of the interpretations is in the minority The java date always agrees with one of the others, and the KNIME handling of dates in the 41-99 range stands out as unusual.
It appears that the rules are:
KNIME - all 2 digit dates are considered to be this century (I’m basing this assumption on the observations above and haven’t seen it documented)
EXCEL - Uses the 2029 rule: All 2 digit dates between 00 and 29 are considered to be 20nn. All two digit dates between 30 and 99 are considered to be 19nn
JAVA - I think uses the 80-20 rule. The date range for 2-digit dates is derived from the set of dates 80 years prior to current date through to 20 years after current date. So a 2 digit date interpreted in 2021 could (on the boundaries) give a different result to one interpreted in 2020 or 2022.In 2021, the 80-20 year span is considered to be 1941 to 2040, so years in the range 41-99 and 00-40 are in the range 1941-1999 and 2000-2040 respectively.
So… the bottom line here I guess is that when it comes to two-digit years, you need to make sure you know what range YOU understand them to mean, and check that they are interpreted correctly in your workflow. Remember that the interpretation can differ according to the node used. Ideally, have the dates corrected at source, and never intentionally create them, so that there is no ambiguity.
And my final thought is that I really don’t envy all the future KNIMERS waking up on
1 Jan 10000 … Fixing the old data for Y2K was bad enough!