<div dir="ltr"><div class="gmail_default" style=""><span style="font-family:"times new roman",serif;color:rgb(80,0,80)">The </span><span style="color:rgb(80,0,80);font-family:"times new roman",serif">Unicode ICU team</span><span style="color:rgb(80,0,80);font-family:"times new roman",serif"> discussed the proposed changes in the TZDB in their meeting earlier this week and we </span><span style="color:rgb(80,0,80);font-family:"times new roman",serif">are reporting the consensus here. This is an initial report, since time is short.</span></div><div class="gmail_default" style=""><span style="font-family:"times new roman",serif;color:rgb(80,0,80)"><br></span></div><div class="gmail_default" style=""><span style="font-family:"times new roman",serif;color:rgb(80,0,80)">Members are very concerned about the downstream impact, and the inevitable compatibility mismatches between different implementations. While the pre-1970 data may not seem important to some people, the instability caused by its removal can be considerable, and last for years to come. </span><span style="font-family:"times new roman",serif">Even if the TZDB provides a way to produce data compatible with 2021a or before by option, this may introduce confusion. For example, an OS packager may pick a default data package with pre-1970 rules merged, while a library packager like ICU may pick a variant with pre-1970 data preserved. Previously, multiple implementations used a single data so there is general consistency. With the proposed plan, there could be differences in results before 1970 between multiple implementations, causing problems everywhere - e.g. Linux and Java, ICU and Linux, etc.</span><br><font color="#500050" face="times new roman, serif"><br></font><span style="font-family:"times new roman",serif;color:rgb(80,0,80)">If the change is made, here are the probable steps that would happen in ICU, based on the two areas that would be affected.</span><br><font color="#500050" face="times new roman, serif"><br></font><b><span style="font-family:"times new roman",serif;color:rgb(80,0,80)">1. Dropping zone IDs from the zone.tab.</span><br></b><span style="font-family:"times new roman",serif;color:rgb(80,0,80)">The main impact here is that a lot of implementations rely on the mapping of zone IDs to ISO country codes. ICU already has an internal exception table that contains certain (zone IDs, ISO code) mappings that retains information that used to be in zone.tab. We would extend that table to add all of the zones dropped by the proposed change. We would probably also move the data and the rest of zone.tab to CLDR, so that we have a public, structured set of data in XML and JSON. This would effectively clone the zone.tab data.</span><br><font color="#500050" face="times new roman, serif"><br></font><span style="font-family:"times new roman",serif;color:rgb(80,0,80)">That way, implementations could use the zone.tab information to maintain the difference between Europe/Oslo and Europe/Berlin. That is, while the internal software might map Europe/Oslo to </span><span style="color:rgb(80,0,80);font-family:"times new roman",serif">Europe/</span><span style="color:rgb(80,0,80);font-family:"times new roman",serif">Berlin via a Link to get rules for evaluation, the library would still treat Europe/Oslo as a separate ID from Europe/Berlin.</span></div><div class="gmail_default" style=""><font face="times new roman, serif"><br></font><font color="#500050" face="times new roman, serif"><br></font><b><span style="font-family:"times new roman",serif;color:rgb(80,0,80)">2. Removing the pre-1970 rules</span><br></b><span style="font-family:"times new roman",serif;color:rgb(80,0,80)">Or rather, moving the pre-1970 data into a file that is mixed in with other data that is not currently used. ICU doesn't want to get into the business of maintaining a fork of the TZDB, but if another major industry player took that role on, then ICU would consider adopting it so that the data is maintained.</span><br><span class="gmail-im" style="color:rgb(80,0,80)"><div class="gmail_default" style="font-family:"times new roman",serif"><div class="gmail_default"><br></div></div></span><span style="font-family:"times new roman",serif">Mark Davis, Unicode Consortium President and Chair of CLDR</span></div><div class="gmail_default" style=""><span style="font-family:"times new roman",serif">Yoshito Umaoka, Vice Chair of ICU</span><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 24, 2021 at 3:38 AM 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">On Fri, 24 Sept 2021 at 11:05, Eliot Lear via tz <<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a>> wrote:<br>
> Before you put out a "good final position", could you please respond to<br>
> Paul on his compromise proposal.<br>
<br>
I think I did just that.<br>
<br>
The compromise of a short delay is good. The compromise position of<br>
smaller chunks of link-merging is unnecessary if we can agree on a<br>
better alternate solution. Once a better approach is agreed we can lay<br>
down a specific plan in advance to roll it out, effectively<br>
side-stepping the negative aspects of multiple separate link-merges.<br>
As such, it makes no sense to have any link merging in 2021b.<br>
<br>
(Paul's compromise position is unclear as to whether he intends to<br>
have no link-merging in 2021b, or just a smaller amount. Given the<br>
immediate damage a link-merge causes Joda-Time's millions of users, I<br>
don't have the ability to compromise on the contents of 2021b wrt<br>
link-merging. But I do have the ability to seek a consensus solution<br>
that can be rolled out in a planned manner, even if that requires<br>
changes to Joda-Time.)<br>
<br>
Stephen<br>
</blockquote></div>