[tz] Some thoughts about the way forward

[Jon Skeet]

On Sat, 25 Sept 2021 at 06:45, Paul Eggert via tz <tz at iana.org> wrote:

> On 9/24/21 7:32 PM, Deborah Goldsmith wrote:
> > AFAIK Apple software doesn’t have a problem with length, just the
> pattern, which currently follows the spec.
>
> Yes, thanks for bringing that up. We should consider that in any version
> number variant we might want to use in the near future.
>
> If I read the spec correctly, the pattern Apple uses should be
> equivalent to the POSIX extended regular expression '[0-9]{4}z*[a-z]' in
> the C locale. Am I right about Apple's pattern?
>
> Also, does Apple software insist that version numbers must be in strict
> order? For example, does it require that the version after '2021zz' must
> be either '2021zza' or a version Ya where Y is a four-digit year greater
> than 2021? or could the next version after '2021zz' be anything matched
> by the abovementioned pattern? The spec is silent on this subject.
>

Might I suggest we consider creating a simply-sortable order that naturally
allows for more than 26 releases?
That could be as simple as starting with 2023aa, 2023ab...2023az, 2023ba,
2023bb... 2023bz, 2023ca. etc.

I really hope we never have to cope with more than 676 releases in a year :)

> If you propose changing it, there needs to be a new spec, and a
> considerable period of time (preferably a year) to adjust to it.
>
> Yes, quite so. Plus, the above details should be nailed down. (And the
> spec

should be extended so that it clearly allows year numbers greater

than 9999 - even though there should be *plenty* of time before that
> particular flexibility is needed....)
>

I suspect that doing so is likely to be burdensome for very little benefit.
I suspect that designing a filename format expected to be stable for longer
than 7000 years is futile, whereas there are simplicity benefits in having
a fixed year length.

If there's ever a sub-group mailing list set up for this (or however we
want to discuss it) I'd be happy to be part of it.

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20210925/7c21d092/attachment.html>