> As I understood things then, CLDR and Java's
> localization code and data could not handle BC standard time that is 7
> rather than 8 hours behind UTC

This is correct for CLDR 48.1 and earlier.

> If CLDR and OpenJDK already support BC standard time at -07, does that
> mean that TZDB's temporary hack is no longer needed and can be removed
> in the next TZDB release?

The hack is not needed for OpenJDK, because they updated to the latest CLDR version before updating to 2026b. Not every system does that, especially because this was a minor CLDR release.

On Thu, 2 Jul 2026 at 00:05, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2026-07-01 14:49, Robert Bastian wrote:
> CLDR made the required changes for 2026b in 48.2, which was released on
> 2026-03-17.
>
> OpenJDK had incorporated 2026b by 2026-04-30:
> https://bugs.openjdk.org/browse/JDK-8383645.

Oh, then I suppose I misunderstood the problems that were discussed on
this list in March. As I understood things then, CLDR and Java's
localization code and data could not handle BC standard time that is 7
rather than 8 hours behind UTC, and that is why TZDB 2026b has a
temporary hack to delay until November this change to BC standard time
(even though that change actually occurred on March 9).

If CLDR and OpenJDK already support BC standard time at -07, does that
mean that TZDB's temporary hack is no longer needed and can be removed
in the next TZDB release? Or, if it shouldn't be removed, does this mean
there will still be integration problems in October?