Historic timezone offsets in newer JDK versions

Question

I found a weird java discrepancy while testing some timezones with the use of ZonedDateTime. I was trying to parse a date before 1970 and saw that the result changes between java versions. The offset for Netherlands in 1932 is +00:19. Does anyone know why this happens? I feel this might be related with the bundling of european timezones in the time zone database project (https://github.com/eggert/tz), but i’m not sure. Is there a way to get the old behavior in java? Like with a setting?


ZonedDateTime zdt = LocalDateTime.parse("1932-10-20T10:19:32.000").atZone(ZoneId.of("Europe/Amsterdam"));
System.out.println(zdt);
    
DateTimeFormatter formatter = new DateTimeFormatterBuilder()
    .append(ISO_LOCAL_DATE)
    .appendLiteral('T')
    .appendValue(HOUR_OF_DAY, 2)
    .appendLiteral(':')
    .appendValue(MINUTE_OF_HOUR, 2)
    .optionalStart()
    .appendLiteral(':')
    .appendValue(SECOND_OF_MINUTE, 2)
    .optionalStart()
    .appendFraction(NANO_OF_SECOND, 3, 3, true)
    .appendOffset("+HH:MM", "Z")
    .toFormatter();

System.out.println(formatter.format(zdt));

System.out.println(
    java.time.zone.ZoneRulesProvider
                  .getVersions("UTC")
                  .lastEntry()
                  .getKey()
);

Result in Temurin (java jdk) 11.0.16 (expected output), last line showing timezone database version:

1932-10-20T10:19:32+00:19:32[Europe/Amsterdam]
1932-10-20T10:19:32.000+00:19
2022a

Result in Temurin 11.0.17:

1932-10-20T10:19:32Z[Europe/Amsterdam]
1932-10-20T10:19:32.000Z
2022c

Edit: Also an issue in JDK 17 starting from 17.0.5:

Temurin 17.0.4:

1932-10-20T10:19:32+00:19:32[Europe/Amsterdam]
1932-10-20T10:19:32.000+00:19
2022a

Temurin 17.0.5:

1932-10-20T10:19:32Z[Europe/Amsterdam]
1932-10-20T10:19:32.000Z
2022c

Timezone database versions per JDK version: oracle.com/java/technologies/tzdata-versions.html — 10 hours ago
I checked a few versions of the tzdb and found that the amsterdam zone got moved from the europe file to the backzone file. Other than that, I couldn’t find any significant changes on the versions I checked (all 2020a+). It might be helpful if you can specify what version of tzdb you are using. — 9 hours ago
Okay, I found it. It is this line in this commit. They basically made Amsterdam an alias of Brussels because they share the same times post-1970. 2022b was the first version this change was applied to, it seems. — 8 hours ago
I’ve found a related issue thread for the Corretto JDK here: github.com/corretto/corretto-17/issues/100 — 8 hours ago

score 9 · Accepted Answer · 2023-02-06 12:40:40Z

Disclaimer: I’m a colleague of OP. This issue has half the office baffled.

Helped along by comments by @Sweeper below the question, I think we’ve found the cause.

Background

The venerable Timezone Database did some housecleaning in 2022, and archived a lot of pre-1970 timezone data in their backzone file for version 2022b. This allowed them to merge, for example, Europe/Brussels and Europe/Amsterdam in the leaner post-1970 database (because after 1970, these are in fact equal).

They also introduced a special option (PACKRATLIST) for building the timezone database with the historic timezones intact.

OpenJDK updated to the new version of the Timezone Database, but chose to use the version without historical data, and subsequently, some developers noticed things breaking.

The relevant OpenJDK bug however currently lists supporting the backzone as won’t fix.

Affected JDK’s

Java 11 from 11.0.17 onwards.
Java 17 from 17.0.5 onwards.

Possible solutions

Perhaps newer JDK’s will fix this after all? Unknown at this moment.
Alternatively, use the newer JDK’s, but apply this workaround to install an older version (2022a) of the Timezone Database instead.
Or, rewrite all code that depends on this historical data, possibly by hardcoding the relevant timezone offsets if it is a limited set.

Thanks. You may want to spell out the workaround from Coretto in the answer itself since this seems to be short-term safest and least hacky solution and since I am not sure whether the comment on the Corretto issue will stay for the lifetime of Stack Overflow. — 6 hours ago

Historic timezone offsets in newer JDK versions