<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 3:38 AM Almaz Mingaleev 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">Does that mean that libc APIs will behave differently from whatever<div>is using ICU files?</div></div></blockquote><div><br></div><div>yes, this is already true, and...</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>On Android we are waiting for ICU/CLDR patches because we offer</div><div>libc, ICU, and several Java APIs.</div></div></blockquote><div><br></div><div>...exactly the reason Android does this :-)</div><div><br></div><div>(we learned this the hard way a decade ago when we updated tzdata but not icu, and the results of date formatting suddenly depended on which API you used :-( in a sense it doesn't matter --- 99.999% of dates/times a *user* sees on Android have come from icu rather than libc, but that also means that updating tzdata without icu is not as useful as you might otherwise imagine.)</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>I believe Apple also waits for ICU/CLDR patches, though I do not know</div><div>their reasons.</div></div></blockquote><div><br></div><div>i'm not aware of *any* libc that uses icu (or cldr data directly) for this[1], so everyone's in the same boat.</div><div><br></div><div>____</div><div>1. "this" being specifically just the time/date stuff. note that bionic does, for example, defer to icu for all the iswprint() and wcwidth() type stuff. i wanted to do the same for iconv() but never worked out how to bridge the API gap between that and icu. i've never tried with the date/time stuff, and i'm not aware that anyone else has, so if anyone has implementation experience there, i'd love to hear it!</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 class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 2 Dec 2022 at 17:25, Benjamin Drung 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">Hi everyone,<br>
<br>
I am writing this mail with my distribution maintainer hat on since I am<br>
responsible for keeping the tzdata package up-to-date in Ubuntu. I like<br>
to propose to have a single source of truth for timezone data, which<br>
should be the tzdata source package. Updating this package in a<br>
distribution like Debian/Ubuntu should be enough to update all consumers<br>
in the distribution.<br>
<br>
Sadly this is currently not the case. Ubuntu since 20.04 (focal) adds<br>
the four icu source files metaZones.txt, timezoneTypes.txt,<br>
windowsZones.txt, and zoneinfo64.txt from<br>
<a href="https://github.com/unicode-org/icu-data" rel="noreferrer" target="_blank">https://github.com/unicode-org/icu-data</a> to the tzdata source package.<br>
Then it uses genrb and icupkg to generate the .res files. Since the icu<br>
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).<br>
<br>
metaZones.txt, timezoneTypes.txt, and windowsZones.txt are generated<br>
using tools/cldr/cldr-to-icu/build-icu-data.xml from<br>
<a href="https://github.com/unicode-org/icu" rel="noreferrer" target="_blank">https://github.com/unicode-org/icu</a>. zoneinfo64.txt is generated by<br>
tz2icu. build-icu-data.xml uses <a href="https://github.com/unicode-org/cldr" rel="noreferrer" target="_blank">https://github.com/unicode-org/cldr</a> as<br>
input to convert the cldr data to icu. If I saw that correctly, only<br>
common/supplemental/metaZones.xml needs to be updated there on an<br>
update.<br>
<br>
Can tzdata include the necessary data and tools to generate<br>
metaZones.xml from its source? Then it would be possible to generate the<br>
icu data from the tzdata source without the need to wait for icu to<br>
catch up. Then Debian/Ubuntu can ship a tzdata-icu package for it [1].<br>
<br>
[1] <a href="https://bugs.debian.org/954112" rel="noreferrer" target="_blank">https://bugs.debian.org/954112</a><br>
<br>
-- <br>
Benjamin Drung<br>
Debian & Ubuntu Developer<br>
</blockquote></div>
</blockquote></div></div>