<div dir="ltr">The proposed time zone merges won't affect many Android users,<div>so Android is likely to continue to use official TZDB releases (as ICU),</div><div>albeit the rearguard data set (as ICU).<br><br>Android users primarily need correct local time offsets for the recent</div><div>past, the current moment and a few years into the future.<br><br>Android stopped to use backzone data in Pie (released in 2018) and</div><div>the latest time zone update includes recent time zone merges. There</div><div>were no user reported bugs related to pre-1970 time zone data quality so far.<br><br>On Android we keep metadata which associates zone IDs with ISO country</div><div>codes which is used in time zone picker. Paul's recent time zone merges</div><div>caused problems and we had to patch tzdata. I concluded the changes are</div><div>permanent and had time to update our tooling.<br><br>Currently Android relies on TZDB for time zone rules / TZif generation</div><div>excluding the backward file and tzcode for Android's libc. As long as old IDs</div><div>are kept, such merges do not affect Android.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 8 Jul 2022 at 13:31, Stephen Colebourne 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">At this point, I think it is established that I disagree with the<br>
basis behind removing data from tzdb for the entirely incorrect and<br>
spurious reason of "equality" (given that it actually makes tzdb less<br>
equal, not more). It is also well established that Paul as tzdb<br>
co-ordinator has complete power here to take whatever action he<br>
chooses, and the list has shown itself unwilling to challenge that.<br>
<br>
I setup global-tz as an automated fork of tzdb with two main purposes:<br>
<br>
1) To provide a convenient and reliable way to access the data as<br>
though changes since 2013 had never happened.<br>
2) To demonstrate what tzdb itself could do to resolve the disagreement.<br>
<br>
<a href="https://github.com/JodaOrg/global-tz" rel="noreferrer" target="_blank">https://github.com/JodaOrg/global-tz</a><br>
<br>
To elaborate on point 2, it would be perfectly possible to change tzdb<br>
as follows:<br>
- create a new "dev" branch where the raw tzdb data lives and is edited<br>
- create a script (GitHub Action) that runs on every commit to process<br>
the dev branch<br>
- the script would process dev branch and create the contents of the<br>
current main branch<br>
- and the script would process dev branch and create the contents of<br>
global-tz on a "global" branch<br>
- a further branch could be created where the data is processed to<br>
remove all pre-1970 data<br>
This would allow global-tz to close, as the same data would then be<br>
available in tzdb (on the global branch). Effectively this would allow<br>
tzdb to take ownership of the fork, but the fork would still exist.<br>
<br>
<br>
I would also encourage downstream consumers to think long and hard<br>
about what they will do should this proposal proceed. Is your project<br>
willing to defend Paul's rationale? Is your project willing to accept<br>
that the German time-zone is considered more important than the<br>
Swedish or Norwegian one? The Netherlands more important than Belgium?<br>
Or the Ivory Coast more important than Iceland? If not, then you are<br>
going to need to switch to global-tz (or find some other solution). It<br>
would be good to see a statement from some larger companies on this<br>
matter (eg. Apple, Oracle, Android/Google etc, RedHat).<br>
<br>
For the record, I have no interest or desire to maintain a fork - it<br>
is simply something forced by what I consider to be unacceptable<br>
changes to tzdb..<br>
<br>
thanks<br>
<br>
Stephen<br>
<br>
On Thu, 7 Jul 2022 at 14:45, Paul Eggert via tz <<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a>> wrote:<br>
><br>
> Release 2021b moved to 'backzone' nine zones whose timestamps since 1970<br>
> were duplicates of other zones, as part of a process that started in<br>
> 2013 in the interests of removing prior inequities, one step at a time.<br>
> If we were to continue this process in the same way, we could install<br>
> the attached proposed patch which would move more zones, chosen via the<br>
> same procedure used for 2021b.<br>
><br>
> It strikes me, though, now that Stephen Colebourne has established a<br>
> mechanism that can let downstream users keep the duplicate-since-1970<br>
> zones, that it may be a more effective use of our time to move the rest<br>
> of the duplicate-si ce-1970 zones now, while no urgent changes are<br>
> pending. This would move another twelve zones if I've counted correctly,<br>
> and would let us more efficiently turn our attention to other issues.<br>
><br>
> Comments welcome.<br>
</blockquote></div>