Europe/Amsterdam timezone is now broken due to error in tz update 2022c.

[rzwitserloot]

This is the last version with the correct tz info for Europe/Amsterdam:

corretto-17/make/data/tzdata/europe

Line 2215 in 9068185

0:20 Neth +0020/+0120 1940 May 16 0:00

The next commit basically says 'amsterdam is exactly like brussels'. Amongst other things, it changes the moment when Europe/Amsterdam joins the modern age, timewise, from the correct May 16th 1940, to the incorrect May 20th 1940. (It's correct for Brussels; it's not correct for Amsterdam. Nazi germany changing timezones on countries they occupied, and said countries not reverting to their pre-war state after being liberated, explains these dates).

I'm not familiar enough with the rules about timezone stuff to know if this is an error in corretto or an error in tzdata. However, the upshot is rather drastic. Code like this:

Date d = new Date(40, 2, 1); // cruddy old broken API, I know
System.out.println(d.getTime()); // wrong answer!

is broken for any date before may 20th (not just between may 16th and may 20th 1940). At least, it's clearly wrong in that range, and before that range, it's inconsistent with prior versions. I can run this code:

Date d = new Date(37, 8, 2);
System.out.println(d.getTime());

And when I upgrade/downgrade between Corretto v17.0.4.9-1 and Corretto v17.0.5.8-1, this prints different numbers, without changing the TZ at all (it's set to Europe/Amsterdam on this machine, with the RTC on UTC, on ubuntu running on ec2).

I believe v17.0.4.9-1 gives the right answer, and v17.0.5.8-1 gives the wrong answer.

This has far reaching deleterious effects: for example, DATE columns in h2 now report the wrong date (off by a day) for any date prior to may 20th, 1940. Evidently because h2 stores millis and not y/m/d for some reason. Any code anywhere that flips between DMY and milli-based storage mechanisms will flat out break for anything prior to may 20th 1940, even when consistently applying the Europe/Amsterdam timezone.

Please advise if the tzdata in corretto is just copied from elsewhere, and that therefore I should be filing this bug elsewhere.

In the mean time, for all affected: Downgrading is the only way I can fix this, if you want e.g. h2 databases to not be unfixably broken if they are storing dates prior to May 20th 1940 and your server is setup in Europe/Amsterdam zone.

[caojoshua]

I can reproduce this. For now, I'll assume 17.0.4.9-1 is correct, and 17.0.5.8-1 is incorrect.

Correttos that produce 'correct' output:

• all Corretto-8's
• all Corretto-11's
• 17.0.4
• 19.0.0

'incorrect' output:

• 17.0.5
• 19.0.1

Something must have went into the most recent release of Corretto 17 and 19, that did not go into 8 and 11. I need to look further into this

[alvdavi]

For clarification, the timezone data used in Corretto is the IANA timezone database. We either get that information through the OpenJDK repository, or we do an import ourselves.

The specific change to the Europe/Amsterdam timezone was done in 2022b:
https://github.com/eggert/tz/blob/main/NEWS#L136

Specifically in this commit eggert/tz@0b925f6#diff-b11f203e8e6ce90d0ab5a01a37ac248669987afb2a50fe0224fa8b8c5c985a73

Update 2022b was released on August, so this is the first version of Corretto that includes them. I suggest you contact the Timezone database maintainers for this issue.

[rzwitserloot]

@alvdavi ah, that link helps and clarifies things a lot.

Update 2022b was released on August, so this is the first version of Corretto that includes them. I suggest you contact the Timezone database maintainers for this issue.

No, this seems like an error in corretto. At least, if I understand the diff (0b925f6) you linked to. A quote from this post on the tz-announce list:

Finish moving to 'backzone' the location-based zones whose
timestamps since 1970 are duplicates; adjust links accordingly.
This change ordinarily affects only pre-1970 timestamps, and with
the new PACKRATLIST option it does not affect any timestamps.
In this round the affected zones are Antarctica/Vostok,
Asia/Brunei, Asia/Kuala_Lumpur, Atlantic/Reykjavik,
Europe/Amsterdam, Europe/Copenhagen, Europe/Luxembourg,
Europe/Monaco, Europe/Oslo, Europe/Stockholm, Indian/Christmas,
Indian/Cocos, Indian/Kerguelen, Indian/Mahe, Indian/Reunion,
Pacific/Chuuk, Pacific/Funafuti, Pacific/Majuro, Pacific/Pohnpei,
Pacific/Wake and Pacific/Wallis, and the affected links are
Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland, Pacific/Ponape,
Pacific/Truk, and Pacific/Yap.

Changes to build procedure
The Makefile has a new PACKRATLIST option to select a subset of
'backzone'. For example, 'make PACKRATDATA=backzone
PACKRATLIST=zone.tab' now generates TZif files identical to those
of the global-tz project.

Not sure what the PACKRATLIST is, but the change was intentional: There's a backzone file (see this commit) that now contains the appropriate entries for the Europe/Amsterdam zone pre-1970.

Evidently, to include support for pre-1970 tz effects, the way corretto copies this stuff over needs to be adjusted to take the backzone file into account.

That, or corretto needs to announce this is a major breaking change that breaks many applications that store/interact with dates pre-1940. Which, for at least another decade or two, includes lots and lots of birthdates.

I'll take the campaign over to the tz project if I have to, but they seem to have split things into two not so much to say 'everything before 1970 is irrelevant', but more: "if you can disregard everything before 1970, we have cleaned this thing up a lot, but if you do care, there's the backzone that you should include'. In that sense, it's corretto/openJDK that needs to decide whether it should include backzone or not, and I think the choice should obviously be: Yeah, include it.

[alvdavi]

Hi, I apologize for my previous comment. You're right, the data for the Amsterdam zone was moved to one of the backzones, and although some discussion on the OpenJDK project was held here, the OpenJDK project does used the merged databases.

We are currently investigation potential ways to move forward

[rzwitserloot]

@alvdavi I'm learning as I read here, the links you posted earlier really filled in lots of missing pieces, and so does this link to the OpenJDK discussion. Joda "JSR310" Stephen himself is also on the case, and I can confirm that, yeah, ditching the backzone means all heck breaks loose for at least one of the countries he named: The Netherlands :)

If there's anything I can do to help, let me know. In the mean time I'll keep on eye out on this issue + JDK-8293967 which is evidently related? The 'adopt 2022b' issue you linked to is also currently set as 'wontfix', which is weird, because the current state of the openjdk (at least, the git clone), here, is 2022e based (and therefore broken for e.g. The Netherlands pre-1970).

[alvdavi]

The reason why the 2022b was marked as won't fix was because shortly after, 2022c was released and that version was imported directly, skipping the 2022b update (but with the 2022c import commit containing all the 2022b + 2022c changes)

[caojoshua]

Correttos that produce 'correct' output:

all Corretto-8's
all Corretto-11's
17.0.4
19.0.0
'incorrect' output:

17.0.5
19.0.1

Need to make a correction. I've tried this again. All Correttos (8, 11, 17, 19) prior to the Q4 release produce correct output. All Correttos after the release produce the incorrect output. We need a path forward for all Corretto versions.

We are going to discuss this issue with upstream maintainers.

[caojoshua]

All Corretto 2022 Q4 release on 2022/10/18 (8.352.08.1, 11.0.17.8.1, 17.0.5.8.1, 19.0.1.10.1) include 2022b timezone updates. This update merges the Europe/Amsterdam timezone with Europe/Brussels, and breaks pre-1970 Netherlands dates. This in an intended change by the IANA Timezone Database. Older timezones are available as backzones

The OpenJDK community discussed this issue in https://bugs.openjdk.org/browse/JDK-8292223, and ultimately decided to import timezone data without backzones. Corretto will continue to use timezone data without backzones to maintain compatibility with other OpenJDK distributions. The Corretto team will work with the community to address this issue for a future release.

As a workaround, you can use the Timezone Updater Tool to have your JDK use 2022a tzdb and have correct data on the Netherlands. You can download the tzupdater jar from here. Example:

java -jar tzupdater.jar -v -f -l https://www.iana.org/time-zones/repository/releases/tzdata2022a.tar.gz

Note that you will miss updates for some countries such as Chile and Jordan. If this approach is not suitable, you will need to build a custom tzdb. Please reach out if you have further questions or concerns.

[rzwitserloot]

Probably goes without saying, but just in case: Yes, running java -jar tzupdater.jar -v -f -l https://www.iana.org/time-zones/repository/releases/tzdata2022a.tar.gz on Corretto-17.0.5.8.1 (with sudo - or at least, ensure that JVM has the rights to write to its own installation) restores the behaviour to 2022a levels - i.e. fixes pre-1970 for The Netherlands and other affected timezones.