<div dir="ltr"><div dir="ltr"><br></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">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><br></div><div>it's possible i'm adding more confusion here (in which case tell me and i'll shut up) because i haven't done any of these updates in many years now (thanks, almaz and others!), but the problem we had in the past that i alluded to was that icu4c's date formatting was using its own copy of the _transition_ data. so format via libc and you get the tzdata transitions (we're using more-or-less tzcode directly), but format via icu4c (which is almost every string in the UI) and you'd be using the transition data bundled with icu.</div><div><br></div><div>if that's no longer duplicated, and it's only the _strings_ now, that's awesome, and nothing i've said (in this mail or my previous one) is relevant (for which i apologize!).</div></div></div>