<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Perhaps the tzdb *should* maintain a notion of "metazones", giving them names; it would leave it up to the CLDR to assign localized abbreviations and display names for them.<br class="gmail-Apple-interchange-newline"></blockquote><div><br></div><div>If TZDB has the information to do this, and it doesn't open the TZDB maintainers up to more geopolitical headaches than today, I personally think that's a good idea. I'm assuming it would actually be usable for downstream folks.</div><div><br></div><div>Somebody on the CLDR side may come along later and point out where the art lies in all this and why TZDB may want to steer clear. They've been tracking TZDB updates for years so they have probably encountered any issues along the way.</div><div><br></div><div>One disconnect I'm aware of, in the past (at least) CLDR liked to have identifier stability. As I understand it, they have declared their zone IDs as "stable" (canonical, I think, in their nomenclature). Although I think TZDB already gives guarantees about never removing IDs, CLDR commit to not changing the ones they use. Although they recognize all TZDB's zone IDs, adding new ones as needed, they still use ones like Asia/Calcutta internally as their keys in preference to Asia/Kolkata. If there were an appetite for TZDB to start mastering metazones, they might find guarantees useful around metazone IDs not shifting over time so they wouldn't need to build in indirection.</div><div><br></div><div>As a side note, I was also present at some recent discussions where, for embedded usage, ICU folks were considering "short" IDs for some time zone concepts. I confess I don't remember / didn't catch the details, but it was something to do with some low level Rust types and I think the concern that the TZDB IDs are quite long and not that friendly for IoT devices. It's well off topic for this thread, but I thought I'd mention in case there is any appetite for TZDB to become the authority for that too, i.e. perhaps it could also master a new set of aliases for zone IDs with length / stability guarantees. This is highly speculative on my part.</div><div><br></div><div>Neil.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 13 Apr 2021 at 19:52, Guy Harris <<a href="mailto:gharris@sonic.net">gharris@sonic.net</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 Apr 13, 2021, at 7:26 AM, Neil Fuller via tz <<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a>> wrote:<br>
<br>
> All that said, metazones could perhaps be ignored as an implementation detail used to derive a name for a zone ID.<br>
<br>
Perhaps the tzdb *should* maintain a notion of "metazones", giving them names; it would leave it up to the CLDR to assign localized abbreviations and display names for them.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Google UK Limited<br><br>Registered Office: 6 Pancras Square, London, N1C 4AG<br>Registered in England Number: 3977902</div></div></div></div></div>