[tz] Some thoughts about the way forward

Jon Skeet skeet at pobox.com
Fri Sep 24 08:08:17 UTC 2021

On Fri, 24 Sept 2021 at 08:51, Paul Eggert <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
> 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
> things.

 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...
URL: <https://mm.icann.org/pipermail/tz/attachments/20210924/1de96e10/attachment-0001.html>

More information about the tz mailing list