<div dir="ltr">What equity, diversity or inclusion issues were in 2021a? <div>How does the patch solve them or make the situation better?</div><div>Is there a roadmap?</div><div><br></div><div>There were multiple requests about Kiev -> Kyiv rename. And the patch</div><div>can be interpreted as prioritising some time zones over the others.</div><div>Won't it cause even more requests of that kind?</div><div><br></div><div>Sorry if it was already answered, I couldn't find answers to these questions</div><div>in archives.</div><div><br></div><div>Thanks,</div><div>Almaz</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 20 Sept 2021 at 17:16, Paul Eggert via tz <<a href="mailto:tz@iana.org">tz@iana.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/20/21 1:06 AM, Stephen Colebourne via tz wrote:<br>
<br>
> The purpose of the fork would<br>
> initially be to maintain the tzdb data set as it was prior to the<br>
> dispute.<br>
<br>
Such a fork would arbitrarily discriminate against countries like Angola <br>
and Niger, and in favor of countries like Norway and Sweden.<br>
<br>
A primary goal of the recent patches was to avoid racial or national <br>
preferences that were present in the previous setup. Arguably these <br>
preferences were not intentional, or were apparent and not real; <br>
however, that's not an argument I would want to defend.<br>
<br>
Although the problem of discrimination could also be fixed in the fork <br>
you suggest, any such fix would take considerable work. It couldn't be <br>
done merely by reverting a patch or two. All this work would be need to <br>
be done before any such fork could be used by an organization that is <br>
committed to equity, diversity and inclusion.<br>
<br>
Instead of forking, I suggest that we work together to address the <br>
technical issues raised by the change. I've been attempting to do that <br>
with the recent "Revert May patch to zone.tab" patch, which Almaz today <br>
said fixes the problems Google had with region-timezone mapping. I hope <br>
that we can address remaining technical problems with similar patches.<br>
<br>
If the "Revert May patch to zone.tab" patch is not enough, one possible <br>
path forward would be to add a build-time option along the lines that I <br>
suggested to Tom Lane in <br>
<<a href="https://mm.icann.org/pipermail/tz/2021-June/030197.html" rel="noreferrer" target="_blank">https://mm.icann.org/pipermail/tz/2021-June/030197.html</a>>. This would <br>
let projects like PostgreSQL generate a tzdata.zi file containing <br>
whatever backzone entries they choose, though I would urge these <br>
projects to consider equity, diversity and inclusion issues when they <br>
make their choices. I have drafted a patch along these lines and could <br>
circulate it if there's interest.<br>
<br>
The idea is to commit to an approach that accommodates users who need at <br>
least one tzdb entry per country, either via the "Revert May patch to <br>
zone.tab" or by further patches if necessary.<br>
<br>
 > These have the effect of wiping out historic time-zone<br>
 > information on many locations where the data has been in tzdb for many<br>
 > years.<br>
<br>
None of the information has been "wiped out". It has merely moved from <br>
one source file to another, and builds with PACKRATDATA=backzone still <br>
install all the info in question. This disagreement is not about "wiping <br>
out" info; it's about what category the info falls into.<br>
</blockquote></div>