[tz] Moving more zones to 'backzone'

[Almaz Mingaleev]

The proposed time zone merges won't affect many Android users,
so Android is likely to continue to use official TZDB releases (as ICU),
albeit the rearguard data set (as ICU).

Android users primarily need correct local time offsets for the recent
past, the current moment and a few years into the future.

Android stopped to use backzone data in Pie (released in 2018) and
the latest time zone update includes recent time zone merges. There
were no user reported bugs related to pre-1970 time zone data quality so
far.

On Android we keep metadata which associates zone IDs with ISO country
codes which is used in time zone picker. Paul's recent time zone merges
caused problems and we had to patch tzdata. I concluded the changes are
permanent and had time to update our tooling.

Currently Android relies on TZDB for time zone rules / TZif generation
excluding the backward file and tzcode for Android's libc. As long as old
IDs
are kept, such merges do not affect Android.

On Fri, 8 Jul 2022 at 13:31, Stephen Colebourne via tz <tz at iana.org> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20220708/e053bcf2/attachment.html>