<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 8, 2022 at 12:00 PM Mark Davis ☕️ 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"><div dir="ltr"><div style="font-family:"times new roman",serif">> <span style="font-family:Arial,Helvetica,sans-serif">As I understand it, if TZDB releases version X, Android and Apple</span></div>currently wait for ICU/CLDR to release a new version that takes X's<br>changes into account.<div><br></div><div><div style="font-family:"times new roman",serif">The only changes that CLDR worries about are ones that would have an effect on the choice of 'labels' in formatting dates and times. You can see some of those in <a href="https://unicode-org.github.io/cldr-staging/charts/42/verify/zones/fr.html" target="_blank">https://unicode-org.github.io/cldr-staging/charts/42/verify/zones/fr.html</a>. </div></div></div></blockquote><div><br></div><div>i think we might be talking at cross-purposes here? i think you're strictly correct for _cldr_ but i think the questions are really about "the whole of icu", so the fact (i think!) that icu _does_ need to change icu4c/source/data/misc/zoneinfo64.txt in response to tzdata changes is sufficient to be a problem as defined in this thread, even if no new translations are needed for cldr specifically.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div style="font-family:"times new roman",serif">For example, if a version X of the TZDB has no new zones, and changes to the rules for a zone don't require a change to a metazone (e.g. which zones it encompasses, or a new metazone), then nothing needs to happen.</div><div style="font-family:"times new roman",serif"><br></div><div style="font-family:"times new roman",serif">Even when a change is needed, in many cases the normal fallback among the different types of 'labels' means that people will see something reasonable until an implementation upgrades to the latest CLDR.<br></div><div style="font-family:"times new roman",serif"><br></div><div style="font-family:"times new roman",serif"><div>Moreover, CLDR has become over time more insulated from unnecessary instabilities in the TZDB, such as changes in spellings for identifiers, changes in the zone1970.tab file (the backward-compatibility aids from the TZDB are extremely helpful for that!), etc.</div><div><br></div><div>However, just as with the TZDB, there are cases where countries change their rules on crazy-short notice, and where CLDR needs to respond quickly. We try to do dot releases for those cases, but often translations for zones or metazones will lag since we have over 100 languages to manage. Offline, people can contact me at <a href="mailto:mark@unicode.org" target="_blank">mark@unicode.org</a> if they have suggestions for improvements.</div></div><div style="font-family:"times new roman",serif"><br></div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font face="'times new roman', serif"><div style="background-color:transparent;margin:0px"><div></div></div><div style="background-color:transparent;margin:0px">Mark</div><div style="background-color:transparent;margin:0px"><br></div><div style="background-color:transparent;margin:0px"><div>[Yoshito is the expert, so he can correct this if some details are off.]</div></div></font><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></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 7, 2022 at 10:08 AM Paul Eggert via tz <<a href="mailto:tz@iana.org" target="_blank">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 2022-12-07 03:37, Almaz Mingaleev via tz wrote:<br>
> Does that mean that libc APIs will behave differently from whatever<br>
> is using ICU files?<br>
<br>
No, as I understand it the idea is to allow automatic rebuilding of the <br>
timezone-related part of the CLDR/ICU data, whenever a new TZDB version <br>
is released, without having to wait for updates from CLDR/ICU.<br>
<br>
As I understand it, if TZDB releases version X, Android and Apple <br>
currently wait for ICU/CLDR to release a new version that takes X's <br>
changes into account. The idea is that we could improve on this by <br>
developing a procedure that, given a new TZDB release X and an older <br>
CLDR/ICU release W, would produce a slightly-modified copy W' of the <br>
CLDR/IDU data that takes X's changes into account, without having to <br>
wait for ICU/CLDR to produce a new version. Of course when ICU/CLDR get <br>
around to producing a new version X themselves, you could discard W'.<br>
<br>
The main obstacles I see to this are:<br>
<br>
* Copyright issues. Unicode, Inc. does not allow people to redistribute <br>
modified versions of their data files, even if the modifications are <br>
clearly needed.<br>
<br>
* Institutional inertia. ICU/CLDR is big and is unaccustomed to moving <br>
fast, and timezone info is not high priority for ICU/CLDR.<br>
<br>
Although we haven't so far seen any sign of interest here from the <br>
Unicode, Inc. side, perhaps they'll get around to it if some big <br>
customers ask them in the right way.<br>
<br>
By the way, what bad things would happen if Android and Apple *didn't* <br>
wait? In other projects I've dealt with, if an upstream program P adds a <br>
new timezone abbreviation "XYT", downstream distros like Ubuntu can <br>
immediately ship the new P without waiting for i18n updates. P will <br>
still work fine in all locales, except that the new "XYT" abbreviation <br>
(should it be needed) will appear as-is until translators catch up. <br>
Could Android and Apple do something similar with timezone-related strings?<br>
</blockquote></div>
</blockquote></div></div>