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