[tz] Preparing to fork tzdb
eggert at cs.ucla.edu
Mon Sep 20 18:04:27 UTC 2021
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
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.
More information about the tz