<div dir="ltr"><div dir="ltr">On Sat, 25 Sept 2021 at 06:45, Paul Eggert via tz <<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a>> wrote:<br></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 7:32 PM, Deborah Goldsmith wrote:<br>
> AFAIK Apple software doesn’t have a problem with length, just the pattern, which currently follows the spec.<br>
<br>
Yes, thanks for bringing that up. We should consider that in any version <br>
number variant we might want to use in the near future.<br>
<br>
If I read the spec correctly, the pattern Apple uses should be <br>
equivalent to the POSIX extended regular expression '[0-9]{4}z*[a-z]' in <br>
the C locale. Am I right about Apple's pattern?<br>
<br>
Also, does Apple software insist that version numbers must be in strict <br>
order? For example, does it require that the version after '2021zz' must <br>
be either '2021zza' or a version Ya where Y is a four-digit year greater <br>
than 2021? or could the next version after '2021zz' be anything matched <br>
by the abovementioned pattern? The spec is silent on this subject.<br></blockquote><div><br></div><div>Might I suggest we consider creating a simply-sortable order that naturally allows for more than 26 releases?</div><div>That could be as simple as starting with 2023aa, 2023ab...2023az, 2023ba, 2023bb... 2023bz, 2023ca. etc.</div><div><br></div><div>I really hope we never have to cope with more than 676 releases in a year :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 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.<br>
<br>
Yes, quite so. Plus, the above details should be nailed down. (And the spec </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">should be extended so that it clearly allows year numbers greater</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
than 9999 - even though there should be *plenty* of time before that <br>
particular flexibility is needed....)<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Jon</div><div><br></div></div></div>