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