[tz] Moving more zones to 'backzone'

[Stephen Colebourne]

At this point, I think it is established that I disagree with the
basis behind removing data from tzdb for the entirely incorrect and
spurious reason of "equality" (given that it actually makes tzdb less
equal, not more). It is also well established that Paul as tzdb
co-ordinator has complete power here to take whatever action he
chooses, and the list has shown itself unwilling to challenge that.

I setup global-tz as an automated fork of tzdb with two main purposes:

1) To provide a convenient and reliable way to access the data as
though changes since 2013 had never happened.
2) To demonstrate what tzdb itself could do to resolve the disagreement.

https://github.com/JodaOrg/global-tz

To elaborate on point 2, it would be perfectly possible to change tzdb
as follows:
- create a new "dev" branch where the raw tzdb data lives and is edited
- create a script (GitHub Action) that runs on every commit to process
the dev branch
- the script would process dev branch and create the contents of the
current main branch
- and the script would process dev branch and create the contents of
global-tz on a "global" branch
- a further branch could be created where the data is processed to
remove all pre-1970 data
This would allow global-tz to close, as the same data would then be
available in tzdb (on the global branch). Effectively this would allow
tzdb to take ownership of the fork, but the fork would still exist.


I would also encourage downstream consumers to think long and hard
about what they will do should this proposal proceed. Is your project
willing to defend Paul's rationale? Is your project willing to accept
that the German time-zone is considered more important than the
Swedish or Norwegian one? The Netherlands more important than Belgium?
Or the Ivory Coast more important than Iceland? If not, then you are
going to need to switch to global-tz (or find some other solution). It
would be good to see a statement from some larger companies on this
matter (eg. Apple, Oracle, Android/Google etc, RedHat).

For the record, I have no interest or desire to maintain a fork - it
is simply something forced by what I consider to be unacceptable
changes to tzdb..

thanks

Stephen

On Thu, 7 Jul 2022 at 14:45, Paul Eggert via tz <tz at iana.org> wrote:
>
> Release 2021b moved to 'backzone' nine zones whose timestamps since 1970
> were duplicates of other zones, as part of a process that started in
> 2013 in the interests of removing prior inequities, one step at a time.
> If we were to continue this process in the same way, we could install
> the attached proposed patch which would move more zones, chosen via the
> same procedure used for 2021b.
>
> It strikes me, though, now that Stephen Colebourne has established a
> mechanism that can let downstream users keep the duplicate-since-1970
> zones, that it may be a more effective use of our time to move the rest
> of the duplicate-si ce-1970 zones now, while no urgent changes are
> pending. This would move another twelve zones if I've counted correctly,
> and would let us more efficiently turn our attention to other issues.
>
> Comments welcome.