<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I guarantee that the name 2021a1 will break tooling and software at Apple. There are tools and OS software with regular expressions based on the documented nomenclature. We can’t release something with a name like that. Please stick to the documented nomenclature.<div class=""><br class=""></div><div class="">Deborah<br class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 24, 2021, at 1:08 AM, Jon Skeet via tz <<a href="mailto:tz@iana.org" class="">tz@iana.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class="">On Fri, 24 Sept 2021 at 08:51, Paul Eggert <<a href="mailto:eggert@cs.ucla.edu" target="_blank" class="">eggert@cs.ucla.edu</a>> wrote:<br class=""></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 9/24/21 12:32 AM, Jon Skeet wrote:<br class="">
> Except that the name 2021a1 is*not* compatible with<br class="">
> <a href="https://data.iana.org/time-zones/tz-link.html" rel="noreferrer" target="_blank" class="">https://data.iana.org/time-zones/tz-link.html</a><br class="">
<br class="">
I don't know of any software that will break due to the name 2021a1. If <br class="">
you know of one, we could issue 2021b and 2021c. I had already <br class="">
considered doing that but thought that it would more problematic than <br class="">
what I ended up proposing, for reasons that I hope are obvious.<br class=""></blockquote><div class=""><br class=""></div><div class="">Concrete issue with Android, from a mail from Almaz Mingaleev:</div><div class=""><br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For <span class="">Android</span> having <span class="">2021a1</span> and 2021b would be inconvenient. Because <br class="">there are hardcoded places which expect that tzdata version is exactly<br class="">5 characters. And we can't update that code along with time zone files.</blockquote><div class=""><br class=""></div><div class="">(I acknowledge that there's already the potential for problems there if 2021aa is ever needed, but there would at least be fairly clear warning that that was coming - by the time we got to 2021p or so, I'd expect it to be looked at seriously.)<br class=""></div><div class=""><br class=""></div><div class="">Concern, though less specific, from Derick Rethans</div><br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I can't remember the last time there was a number after the version letter (so 2004, at the latest), and none of the tooling that I've been involved with will know how to handle this.</blockquote><div class=""><br class=""></div><div class="">Speculative concern from Florian Weimer:<br class=""></div><br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm slightly worried that people have grown to depend on the \d+[a-z]+<br class="">format for version numbers, so this choice of version might break some<br class="">things.</blockquote><div class=""><br class=""></div><div class=""> Known breakage reported by Paul Ganssle (the second sentence):</div><br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is not exactly a guarantee, but 2021a1 does violate that nomenclature, which will likely break scripts that rely on it (I have scripts that actively assert that the version numbering follows this convention, for example).</blockquote></div><div class=""> </div><div class="">So that's a mixture of "we know X and Y will break, and we think other things may do as well". Is that sufficient evidence to convince you that 2021a1 is problematic?</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Making the equitable distribution look like an optional flaky branch is <br class="">
not the way to move forward. It shouldn't be considered optional because <br class="">
fairness ought to be one of our core principles. And it shouldn't be <br class="">
considered flaky because it's not flaky; we've done this sort of thing <br class="">
many times before without significant incident.<br class=""></blockquote><div class=""><br class=""></div><div class="">I wouldn't use the word "flaky" but I <i class="">would</i> say it's experimental, in that we don't genuinely know the impact of a change of <i class="">this</i> scale. I would suggest that we've done "this sort of thing" on a smaller scale.</div><div class=""><br class=""></div><div class="">To look at it another way: what's the absolute urgency here? If you <i class="">just</i> release 2021b as "2021a + Samoa" then we're basically in the position we were in before. If there's a pressing need for the "equitable distribution" to be released, then presumably there was before - but it hasn't been released. It feels to me like "the need to get onto the equitable distribution" (ideally with community consensus, which I think is lacking at the moment) and "the need to get the Samoa changes out" are orthogonal - whereas your proposed releases conflate the two.<br class=""></div><div class=""><br class=""></div><div class="">Jon</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div>
</div></blockquote></div><br class=""></div></div></body></html>