On Mar 26, 2025, at 13:24, Robert Elz <kre@munnari.OZ.AU> wrote:
You're totally misunderstanding the problem. The tzcode part is almost 100% irrelevant in all of this, updates to that are rarely all that important, and no-one much cares when downstream distributions incorporate them, typically there is a delay of several years between when some new feature there is added, and when it might start being used.
I mentioned it only because it's not uncommon for release-related timing to be complicated by data cohabitating with code. It's great if that's not an issue for tzdb, as it definitely has been an issue for other, perhaps more complicated projects. By asking that question, I was fishing for the historical perspective that Paul provided, not making an assertion.
| But I'm of the opinion that the decision of whether to accumulate | changes or release them immediately as updates/patches should rest | with those consumers.
It is all in publicly available git as I understand it, anyone able and willing to use git (which excludes me, I hate it) can fetch and update any time they want to. Few do.
Putting my OS package maintainer hat back on, I can offer up a few reasons that can explain why few pull in updates external to any official tzdb release. First, more effort and attention must be paid to track and maintain such out-of-release (OOR) changes and these OOR changes must be periodically reconciled. In some orgs, releasing packages with OOR changes can be harder to justify, take a longer approval track to implement, allot testing time, and release. In the case of tzdb, the process tends to get a lot smoother once the production of a patch is predicated on a tangible versioned release from upstream. Taking in OOR changes also introduces a situation of version mismatch with upstream. For example, if I ship tzdb 1234a in my OS, and a country commits to a timezone change following that the release of 1234a, I have two options: 1. I can immediately pull in the new tzdb change from git and add it to my product's existing 1234a code, essentially creating a "1234a+" release of my own. I then run that through approvals, testing, and release; getting it into the hands of downstream customers and users as an update. 2. Wait, for a possibly unknown amount of time, until 1234b is released. The only delta between 1234b and 1234a may be just that one timezone change. I would then issue an update versioned as 1234b. The problem with (1) is that I've put myself into a package management quandary. When 1234b comes out, it may be functionally indistinguishable from what I've created on my own, yet the versions will be mismatched due to my creation being based on 1234a + an OOR change. My more astute customers/users, especially ones in any area affected by the tzdb change, will see that I'm shipping "1234a", not the "1234b" that (officially) has their timezone's changes in it. This will introduce doubts that I must then make an effort to explain. When 1234b arrives, do I issue another patch that, essentially, changes nothing but can cause operational disruption? Or, do I true it all up when a presumed 1234c arrives, whenever that might happen? The problem with (2) is the 1234b release, which would have the desired change, may come later than it could have. This shortens the amount of time available to integrate, test, and produce an update, and for users to plan out the patching of their systems. Despite not being in total control of how much lead time there is between a decree and when it comes into effect, as much time as possible is always, always appreciated. Overall, I think life would be simpler if tzdb were rev'd as soon as a timezone change is known about, verified, and the relevant zone files updated in accordance with section 3 of BCP 175/RFC 6557. Months-long wait times so that any additional unrelated changes can be accumulated shouldn't really be a thing; it penalizes an entity who has already made their own decisions. Downstream consumers can choose to skip a release or not. Because it would be a proper release that's tagged, has a proper change log and announcement, the reference is not just some git commit hash. In the end, users can make the final decision whether to apply an update based on information that's traceable back to the very source. In fact, delaying a tzdb release to accumulate unrelated timezone changes could give the wrong impression to the general public, as there is now the /appearance/ of some countries or locales having a different priority than others. I know that isn't the case at all, but the impression would be understandable and the tzdb team would be in a position of having to explain something that is kind of arbitrary in nature to folks who probably don't care for such details. The worst case would be if one country's updates are delayed being officially published due to another country's tz change decision being awaited, and those two countries happen to not be on the best of terms. Improbable, but not impossible, and easily avoidable. Failure of a government entity to notify IANA, and people here often resorting to scouring the news for timezone changes, is much more defensible reason for a late update. But, once we're aware of it and it's verified as fact, then I think it's definitely on "us" to get the change published, not just queued up for whenever. Historical corrections/additions to the database can /probably/ have a more lax approach and be accumulated for the next release, perhaps with a timeout that triggers a release if something more pressing doesn't induce one first. Same with tooling/code changes short of a major bug that must be corrected. /dale