On 2026-07-01 15:29, Robert Bastian wrote:
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.
Thanks for letting us know. As I understand it, this means OpenJDK 27 (currently scheduled for September 15) will have a fix for British Columbia. But I still see issues, as Workday doesn't use OpenJDK. They use Azul Prime, and the past is any guide British Columbia fixes are not likely to hit Azul Prime until six months after OpenJDK 27 is released. This would mean British Columbia localization would be broken in Workday until around March 2027. Workday also uses Node.js for some of user-facing components. If that is Node.js 26.4.0 (released June 24) it should be OK. But as I understand it, Workday's components are often based on older Node.js versions, and if so British Columbia is likely to see trouble there too. Platforms other than Azul Prime and Node.js also need looking into. If I were UBC, I would want to see the exact set of patches from Workday demonstrating how they'll fix timekeeping and localization in British Columbia, for Azul Prime, Node.js, and any other part of their software infrastructure. And if UBC is using any Workday-based middleware I'd want to see the same thing from the middleware providers. Without that, I'd expect to see glitches, almost surely in localization, and possibly even in UT offsets, for British Columbia timestamps starting in November. Alberta is in even worse shape here. Even TZDB hasn't rolled out Alberta patches yet, though we plan to soon. And none of the other platforms I mentioned have fixes for Alberta.
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.
Thanks for mentioning that. I didn't know that the British Columbia problem was fixed in CLDR 48.2. This means some of the commentary in TZDB was incorrect, so I fixed that by installing the attached patch into the TZDB development repository.