On 2022-07-01 10:45:00 (+0800), Stuart Bishop via tz wrote:
On Wed, 29 Jun 2022 at 17:51, Philip Paeps via tz <tz@iana.org> wrote:
On 2022-06-28 20:54:13 (+0800), Martin Burnicki via tz wrote:
even though usually a new version of the DB is only released if some TZ rule was changed, it should not be too hard to simply release a new version now
I strongly disagree with this view.
While the effort required from the tz coordinator to tag a release may be minimal, this is not the case for the many downstream maintainers. Every update presents a risk. Bear in mind that tzdb updates end up being pushed to hundreds of millions of end-user devices, if not more.
Downstream maintainers are cranky enough as-is, following the churn in 2021 (which still has not been completely resolved). If we start tagging tzdb releases without actual tz changes, downstream maintainers will be even more likely to diverge from the closely tracking tzdb. This is ultimately bad news for end users.
For the avoidance of doubt: I completely agree that renaming Europe/Kiev to Europe/Kyiv was the correct thing to do. My objection is to tagging tzdb releases with only commentary changes and no data changes.
Counterpoint, as a downstream maintainer I would appreciate prompt releases for popular requests such as the renaming of Europe/Kiev. Fielding requests and redirecting them to IANA has already taken more time and mindshare than me popping out a new release with updated data. In hindsight I should have added an override and made a release months ago.
All downstream maintainers have been in this boat. But we're a couple of dozen people at most. We have to weigh our efforts fielding email against the risk of updating hundreds of millions of end-user devices. Every update, no matter how trivial, is risky at that scale. Releases without tz changes would do much more harm than good.
If anything, infrequent releases are more of a problem for me (of course I can't speak for other downstreams). The longer between releases, the more likely it is that my release machinery has atrophied, the more accumulated bugs need to be fixed, and under higher time pressure as the release is more likely to have some time critical change included. While I don't think every change prompting a release would be good, I do think an expected release cadence of one release every 3-4 months would be an improvement, along with the occasional unexpected release containing time critical changes.
This is a good suggestion but I don't it's practical. Time zone changes tend to happen in bursts around March and October. If we scheduled releases at the beginning of January, April, July, and October, we'd invariably end up doing at least one additional release in April and October. Shifting the scheduled release to the end of the month, we'd end up doing at least one additional release earlier in the same months. And more often than not, the January and July releases would be devoid of tz changes. As Tom points out, we actually have a fairly predictable schedule today: bursts of releases around the silly seasons in March and October and one or two releases at other times. I'm not too worried about our release machinery atrophying. Unfortunately, the nature of the data we record means we'll always have to make releases on short notice. Considering the end-user impact of every release, making releases with tz changes, only when necessary, is a better compromise than making releases on a schedule, but without tz changes, in addition to releases with tz changes, when necessary. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises