[tz] Some thoughts about the way forward
goldsmit at apple.com
Fri Sep 24 20:01:19 UTC 2021
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.
> On Sep 24, 2021, at 1:08 AM, Jon Skeet via tz <tz at iana.org> wrote:
> On Fri, 24 Sept 2021 at 08:51, Paul Eggert <eggert at cs.ucla.edu <mailto:eggert at cs.ucla.edu>> wrote:
> On 9/24/21 12:32 AM, Jon Skeet wrote:
> > Except that the name 2021a1 is*not* compatible with
> > https://data.iana.org/time-zones/tz-link.html <https://data.iana.org/time-zones/tz-link.html>
> I don't know of any software that will break due to the name 2021a1. If
> you know of one, we could issue 2021b and 2021c. I had already
> considered doing that but thought that it would more problematic than
> what I ended up proposing, for reasons that I hope are obvious.
> Concrete issue with Android, from a mail from Almaz Mingaleev:
> For Android having 2021a1 and 2021b would be inconvenient. Because
> there are hardcoded places which expect that tzdata version is exactly
> 5 characters. And we can't update that code along with time zone files.
> (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.)
> Concern, though less specific, from Derick Rethans
> 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.
> Speculative concern from Florian Weimer:
> I'm slightly worried that people have grown to depend on the \d+[a-z]+
> format for version numbers, so this choice of version might break some
> Known breakage reported by Paul Ganssle (the second sentence):
> 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).
> 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?
> Making the equitable distribution look like an optional flaky branch is
> not the way to move forward. It shouldn't be considered optional because
> fairness ought to be one of our core principles. And it shouldn't be
> considered flaky because it's not flaky; we've done this sort of thing
> many times before without significant incident.
> I wouldn't use the word "flaky" but I would say it's experimental, in that we don't genuinely know the impact of a change of this scale. I would suggest that we've done "this sort of thing" on a smaller scale.
> To look at it another way: what's the absolute urgency here? If you just 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz