[tz] Preparing to fork tzdb

Paul Eggert 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 
<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.


More information about the tz mailing list