<div dir="ltr"><div dir="ltr">On Wed, 7 Dec 2022 at 18:08, Paul Eggert <<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>> wrote:<br></div><div class="gmail_quote"><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></blockquote><div><br></div><div>I've meant how things work now. My concern was around these lines:</div><div><br></div><div>> Since the icu</div>> project lacks behind the tzdata release by hours up to days, Ubuntu has<br>> to update tzdata twice (first the tzdata release, then the icu update).<div><br></div><div>Between these updates you will get different answers from different APIs.</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">
<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></blockquote><div><br></div><div>ICU and CLDR versions are bumped once a year. We do not wait for a new</div><div>version, but for patches only.</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">
<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</blockquote><div> </div><div>On Android we cannot not wait. As I mentioned there are several API</div><div>surfaces and being consistently wrong about _new_ changes is better</div><div>than having different answers within the platform. Also, it takes time to</div><div>prepare and rollout these updates, so not waiting will only cause disruption,</div><div>extra work, and bugs from confused users.</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"> <br>
new timezone abbreviation "XYT", downstream distros like Ubuntu can <br>
immediately ship the new P without waiting for i18n updates. P will</blockquote><div><br></div><div>It is not a problem if a distro ships it, it is a problem if this new stuff leaks</div><div>to the external world. It would be naive to expect from a user base of a service</div><div>to have up-to-date time zone data even after a month after TZDB release.</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"> <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.</blockquote><div><br></div><div>It is not translations that we are waiting for, but changes like [<a href="https://github.com/unicode-org/icu/pull/2261/files" target="_blank">1</a>]. Recent</div><div>time zone changes were short notice ones and ICU team (thanks Yoshito and others!)</div><div>did these changes very quickly. </div><div><br></div><div>[1] <a href="https://github.com/unicode-org/icu/pull/2261/files" target="_blank">https://github.com/unicode-org/icu/pull/2261/files</a> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
Could Android and Apple do something similar with timezone-related strings?</blockquote><div> <br></div></div></div>