<div dir="ltr"><div><span class="gmail-im">&gt; Would such a version bump (if needed) require consumers to upgrade?</span><br><br>Storing an extra, otherwise unused time zone abbreviation a la &quot;@(#) TZID America/New_York&quot; wouldn&#39;t require a version bump; then again, it&#39;s far less clean than what could be done with a version bump.<br><br></div><div>    @dashdashado<br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 9, 2017 at 8:37 PM, Paul Eggert <span dir="ltr">&lt;<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/09/2017 04:44 PM, Steven R. Loomis wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Trying to locate<br>
the actual id of a zone file is itself a huge hassle, as John Layt also<br>
noted in <a href="http://mm.icann.org/pipermail/tz/2015-October/022838.html" rel="noreferrer" target="_blank">http://mm.icann.org/pipermail/<wbr>tz/2015-October/022838.html</a><br>
</blockquote>
<br></span>
Yes, it is a real management hassle that is not trivial to solve. Unfortunately nobody has had the time to come up with a practical solution, as far as I know.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are political objections to some of the zone names, so putting<br>
them in the data files might raise a few eyebrows.<br>
</blockquote></blockquote>
Wouldn&#39;t the names have been filenames elsewhere on disk, somewhere in<br>
the &quot;zoneinfo&quot; directory?<br>
</blockquote>
<br></span>
Not in some installations. Android, I think, does not create filenames like &quot;America/New_York&quot;. More important, these names are not part of the format now, and standardizing them in the format would increase the likelihood of causing political irritations. And still more important, downstream users are free to add to the list of names, and many do so; this lessens the utility of using a &quot;standard&quot; name, as these names are not as &quot;standard&quot; as one might want.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Would such a version bump (if needed) require consumers to upgrade?<br>
<br>
</blockquote>
<br></span>
It seems so -- at least under the proposals I&#39;ve seen so far, as if consumers are running software derived from tzcode, they would need to upgrade, as otherwise the code would mishandle some timestamps. I haven&#39;t looked at non-tzcode-derived libraries but I expect many would be similar. We&#39;d rather avoid this, of course.<br>
</blockquote></div><br></div>