> On Mar 25, 2025, at 19:05, Paul Eggert via tz <tz@iana.org> wrote:
>
> There is a tension between releasing early and delaying a bit, a tension that
> has little to do with Tim's and my maintenance effort. We could release more
> quickly in the future, though this will entail more downstream effort and
> mistakes.
Would it make sense to decouple the "political" data of the timezones
themselves from the technical tooling? This would permit what are essentially
database updates to be distributed on their own, perhaps more aggressive,
cadence. It would avoid any case of being held back due to in-flight or "too
fresh" maintenance work on the tools. It is entirely possible that I could be
overlooking a reason as to why they are tied together into a single entity.
Coming from an OS packaging and maintenance background, I understand the desire
to batch up changes as a courtesy to the immediate downstream consumers of
tzdb. 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. As the origin of this data, I think it would be completely fine for
tzdb to quickly release new versions as timezone changes become known and are
verified as legitimate. I mentioned decoupling the database from the tools as a
way to further facilitate this.
This way, if an OS or app maintainer/vendor is asked by a customer/user if they
have prepared updates for a particular upcoming timezone change of interest,
the maintainer/vendor has the ability to quickly render the necessary update
rather than waiting on the tzdb maintainer to kick out an official update that
they can then use. Because no one can control when timezone changes happen and
how much lead-time there is between the legislation being made and the change
going into effect, any delay might mean vendors might have to issue an 11th
hour update that contains the new timezone data.
I thought I'd mention that I really like the tzdb changelog. The details it
contains are clear and often educational.
> For what it's worth, my guess is that the recent glitches in Paraguay
> wouldn't have been much less numerous even if we had released TZDB in
> October, because the main bottleneck is that people don't install updates.
> It'd be hard to prove this one way or the other, though.
To me, this is just more of a reason to get the info available as soon as
possible after it's known and verified. Put the decision of waiting for more
changes (or not) on the downstream consumers. I imagine the cadence of timezone
changes might pick up over the next years - if it hasn't already - as more
locales seem to be weighing whether to dispense with DST. The tzdb maintainers
can advise if there *might* be additional changes in the near future, such as
in the Paraguay/Philippines situation you mention. But part of an OS
maintainer's job is to weigh and schedule updates based on their user's needs,
and their own release cadence and patching policies. If a user is demanding
updates because they run systems in an affected locale, I would like to be able
to issue that update in short order rather than wait on upstream to decide to
release them.
/dale
