> On Mar 26, 2025, at 13:24, Robert Elz <k...@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
