B.C. Permanent Daylight Savings
Hello, will this database be updating for B.C. switching permanently to Daylight Savings Time? Thank you.
On Wed, 1 Apr 2026 at 13:16, Matthew Lee via tz <tz@iana.org> wrote:
Hello, will this database be updating for B.C. switching permanently to Daylight Savings Time? Thank you.
Yes, the recent change for British Columbia is queued in the development repository awaiting release: https://github.com/eggert/tz/commit/8b46071fd85a7a9434d63894bac64d30362cc16d https://github.com/eggert/tz/commit/8e7dcafc27d697c51dda77bb8804d62eda033c04 There is a bit of a balancing act here: It is prudent to wait a bit to see how nearby border regions (such as Cranbrook) may choose to adapt, whether other jurisdictions join in, or if better guidance on nomenclature develops before releasing. Since BC's change does not affect calculated wall clock times until November 2026, taking a beat to press pause on less urgent changes such as this one allows us to reduce churn in case another change takes place nearby or elsewhere in the world. These and related issues have been discussed at some length in these threads: https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/667WE5QTIA7MP2E7NC... https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/IEZR4HYQXZTUMGRA7F... As Paul pointed out a while ago, absent further news, we expect to release a new update with the changes for British Columbia within the next few weeks, very likely before the end of April. https://lists.iana.org/hyperkitty/list/tz@iana.org/message/UYSPGZ7XUR5ZVR4F4... -- Tim Parenti
* Tim Parenti via tz:
Yes, the recent change for British Columbia is queued in the development repository awaiting release: https://github.com/eggert/tz/commit/8b46071fd85a7a9434d63894bac64d30362cc16d https://github.com/eggert/tz/commit/8e7dcafc27d697c51dda77bb8804d62eda033c04
Some software may also need changes, so that it does not perform a one-hour adjustment if the user (possibly via an application interface) specifies a time with an explicit DST=false setting. Thanks, Florian
Great, thank you for the insight and quick response!
On Apr 2, 2026, at 3:17 AM, Florian Weimer <fweimer@redhat.com> wrote:
[You don't often get email from fweimer@redhat.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
* Tim Parenti via tz:
Yes, the recent change for British Columbia is queued in the development repository awaiting release: https://github.com/eggert/tz/commit/8b46071fd85a7a9434d63894bac64d30362cc16d https://github.com/eggert/tz/commit/8e7dcafc27d697c51dda77bb8804d62eda033c04
Some software may also need changes, so that it does not perform a one-hour adjustment if the user (possibly via an application interface) specifies a time with an explicit DST=false setting.
Thanks, Florian
Hi Tim, I searched for this topic and haven't seen any recent updates. Our organization uses Workday and the vendor indicated that if iana.org takes care of the timezone change, their application will be fine around the time the clock was supposed to change. I am not familiar with the process but I would like to know was is the plan/timeline Thank you, Raul
On 2026-06-30 11:00, Raul Delgado via tz wrote:
Our organization uses Workday and the vendor indicated that if iana.org takes care of the timezone change, their application will be fine around the time the clock was supposed to change.
I am not familiar with the process but I would like to know was is the plan/timeline
TZDB 2026b, released 2026-04-22, already has the BC change. Unfortunately it may take some time for this to percolate into Workday, as Workday uses Java which depends on CLDR for localization of the new time zone, and as I understand things CLDR doesn't plan to have localization fixes until mid-October. So at least localization, and perhaps timestamps, probably will not work until this is sorted out. I assume Java will be fixed soon after CLDR is fixed, and Workday will be fixed soon after that. So it'd be wise to monitor these fixes during October, and to take care when using Workday before October to schedule events after October, as today's Workday may mishandle the times of events scheduled after October in BC. One more thing. We plan to issue a new TZDB release soon, for a similar change planned for Alberta. And there quite possibly will also be similar changes in Northwest Territories and in Nunavik though this has not been legally confirmed yet. These other changes have issues similar to the BC change, for applications like Workday.
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. On Wed, 1 Jul 2026 at 21:08, Paul Eggert via tz <tz@iana.org> wrote:
On 2026-06-30 11:00, Raul Delgado via tz wrote:
Our organization uses Workday and the vendor indicated that if iana.org takes care of the timezone change, their application will be fine around the time the clock was supposed to change.
I am not familiar with the process but I would like to know was is the plan/timeline
TZDB 2026b, released 2026-04-22, already has the BC change.
Unfortunately it may take some time for this to percolate into Workday, as Workday uses Java which depends on CLDR for localization of the new time zone, and as I understand things CLDR doesn't plan to have localization fixes until mid-October. So at least localization, and perhaps timestamps, probably will not work until this is sorted out.
I assume Java will be fixed soon after CLDR is fixed, and Workday will be fixed soon after that. So it'd be wise to monitor these fixes during October, and to take care when using Workday before October to schedule events after October, as today's Workday may mishandle the times of events scheduled after October in BC.
One more thing. We plan to issue a new TZDB release soon, for a similar change planned for Alberta. And there quite possibly will also be similar changes in Northwest Territories and in Nunavik though this has not been legally confirmed yet. These other changes have issues similar to the BC change, for applications like Workday.
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?
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?
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.
On 7/2/2026 3:37 PM, Paul Eggert via tz wrote:
Thanks for mentioning that. I didn't know that the British Columbia problem was fixed in CLDR 48.2.
It appears the fix they implemented in CLDR 48.2 effectively bypasses tzdata for the stdOffset and dstOffset. <timezone type="America/Vancouver"> <usesMetazone mzone="America_Pacific" stdOffset="-08" dstOffset="-07"/> </timezone> Which means another fix will be needed in CLDR 49 due out this fall.
participants (7)
-
Florian Weimer -
James Bellaire -
Matthew Lee -
Paul Eggert -
raul.delgado＠ubc.ca -
Robert Bastian -
Tim Parenti