On Sun, 8 Mar 2026 at 07:43, Dag-Erling Smørgrav via tz <[email protected]> wrote:
> Paul Eggert via tz <[email protected]> writes: > > After reviewing this thread's discussion, the consensus is to delay > > the tm_isdst transition as requested, so I installed the attached > > proposed further patch after talking with Tim. [...] > > Will there be a 2026b with this change in the immediate future? Not "immediate", but soon; see Paul's remarks further down that same message: On Sat, 7 Mar 2026 at 17:00, Paul Eggert via tz <[email protected]> wrote: > This patch removes any need for a TZDB release in the next couple of > days, as TZDB's proposed March 9 entry is now effectively a no-op and > there is no user-visible change in America/Vancouver's behavior until > November. However, we do need a new TZDB release sooner rather than > later because that November change must be user-visible, and TZDB > changes can take time to propagate to devices regardless of whether the > devices also use CLDR. So I'm thinking we wait for further comments and > release TZDB 2026b in a couple of weeks, or April at the latest - unless > some unrelated and more urgent data change comes up, in case we can > simply release. In short, the temporary workaround affords us a bit more time for pre-coordination to gain better confidence on whether "MST" will be suitable in the longer term before we release it, with the goal of minimizing the risk of needing a re-release for further fixes later. On Sun, 8 Mar 2026 at 00:08, Mark Davis Ⓤ via tz <[email protected]> wrote: > Thanks to all involved! The more of a delay the better on the one hand, > but it is also clear that it has to be done *well* before November or > even more serious problems would happen. > > The extra time will allow us to figure out the best approaches both > long-term and short-term, and give clients more time to adjust their > implementations. > Thank you for your understanding. Paul had earlier alluded to the "obvious reasons" of the "more serious problems" caused by waiting too long: People and applications that schedule things like meetings into the future may not care too much about November now, *but they will not wait until November to do so*. While this temporary workaround hacking the tm_isdst bit allows us to press pause on an imminent release for tzdata, the upcoming changes to scheduled UTC offsets do, at the very least, need to start becoming visible to end-users *much closer* to now than to then. Planning to release in a few weeks, closer to the end of the current "silly season", I think, ought to strike that balance about as well as can be managed without knowing in advance what else may arise. We ask for long leadtime not so we can sit on changes, but so we can be as thoughtful as possible about when and how we release them. While I understand the BC Council's apparent inclination to "get things done with" and bring the legislation into official effect from tomorrow, I find it interesting there would have been no practical difference to the Order in Council providing an effective date of 2026-10-31 or even 2026-11-01 instead, more similar to how Yukon implemented their change in 2020. Alas. BC's change has been part of the usual semi-annual DST discussion across North American media this cycle, along with similar latent "trigger legislation" across the continent. So perhaps this may caution other jurisdictions to think carefully about these sorts of details should they choose to move forward. -- Tim Parenti
