[tz] Version in zoneinfo files?

[Arthur David Olson]

> Would such a version bump (if needed) require consumers to upgrade?

Storing an extra, otherwise unused time zone abbreviation a la "@(#) TZID
America/New_York" wouldn't require a version bump; then again, it's far
less clean than what could be done with a version bump.

    @dashdashado


On Thu, Feb 9, 2017 at 8:37 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 02/09/2017 04:44 PM, Steven R. Loomis wrote:
>
>> Trying to locate
>> the actual id of a zone file is itself a huge hassle, as John Layt also
>> noted in http://mm.icann.org/pipermail/tz/2015-October/022838.html
>>
>
> 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.
>
> There are political objections to some of the zone names, so putting
>>>> them in the data files might raise a few eyebrows.
>>>>
>>> Wouldn't the names have been filenames elsewhere on disk, somewhere in
>> the "zoneinfo" directory?
>>
>
> Not in some installations. Android, I think, does not create filenames
> like "America/New_York". 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 "standard" name, as these names are not as
> "standard" as one might want.
>
>
>> Would such a version bump (if needed) require consumers to upgrade?
>>
>>
> It seems so -- at least under the proposals I'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't
> looked at non-tzcode-derived libraries but I expect many would be similar.
> We'd rather avoid this, of course.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20170209/18587003/attachment.html>