On 9/20/21 10:10 AM, Tom Lane wrote:
As far as I can tell, adding PACKRATDATA=backzone does *not* reproduce what was formerly the default set of zones.
It sounds like you formerly did not use PACKRATDATA=backzone and now started using it. That should yield quite a few changes, because it'll use all the 'backzone' data instead of just the data that migrated to 'backzone' recently. This doesn't mean data were lost; on the contrary, it means you're getting more data than before (some of it low-quality and all of it out of tzdb's post-1970 scope). If it's important for PostgreSQL to get data that exactly matches 2021a (except for changes you don't object to), I suggested in <https://mm.icann.org/pipermail/tz/2021-June/030197.html> adding a build-time option to let projects like PostgreSQL choose whatever 'backzone' data they want, instead of 'backzone' being an all-or-nothing decision as it is now. This would let these projects avoid the objected-to changes, while keeping the changes for Samoa etc. that are not objected to, and while at the same time avoiding obsolete or out-of-scope 'backzone' data that they don't want. Of course I would urge these projects to consider equity, diversity and inclusion issues when choosing from 'backzone'; but the choices would be up to them. If you're interested in this approach, I think I could develop it quickly, before any new tzdb release. If not, then let's try to think of a better way to address the issue.
I'm all for improving equity in tzdb's coverage, but I think it should be done by adding coverage for underserved areas
Adding coverage could be part of the laborious process I mentioned in <https://mm.icann.org/pipermail/tz/2021-September/030413.html>. This process would helpful for tzdb, and it would be needed in the proposed fork if the fork wants to satisfy equity, diversity, and inclusion concerns. However, I doubt whether this effort could be done well anytime soon, regardless of whether tzdb is forked.