[tz] Version in zoneinfo files?

Steven R. Loomis srl at icu-project.org
Fri Feb 10 00:44:35 UTC 2017

Thanks to Bradley White in
<http://mm.icann.org/pipermail/tz/2017-February/024814.html> / 
<CAGb2eRP7oT3FpTvJCL=gZDX=VS3=5aiu0GTWT4xUpM-y-x5K8g at mail.gmail.com> for
pointing me to this thread

On 10/27/15 12:25 PM, Brian Inglis wrote:
> On 2015-10-27 11:34, Paul Eggert wrote:
>> Guy Harris wrote:
>>> Which zone name is "the" zone name?  The zone name on the system on
>>> which zic was run?
>> I assume it'd be the name in the Zone directive of the zic input.
>> Presumably zic would also have a new option to specify the version,
>> and Makefile would use the new option. The version and zone name
>> could be appended to the current tzfile format, e.g.,
>> ZONE=America/Los_Angeles
>> VERSION=2015g
>> If you copy or link the file, that wouldn't change its ZONE line.
>> We'd bump the tzfile version number from '3' to '4'. ZONE and VERSION
>> strings couldn't contain newlines. Or perhaps we should use a
>> different convention that allows arbitrary data in strings.
>> This is doable; I'm not sure it's worth the hassle, though. 
I outlined the benefits as a consumer of the tz data. 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

>> 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?
> Perhaps a NUL terminated environment list file suffix like:
>     TIMEZONE \0 America/Los_Angeles \0
>     TZDATA_VERSION \0 2015g \0
>     ZIC_VERSION \0 2015g \0
>     DISTRIBUTION \0 iana.org \0
>     \0 \0
> to which distributions may be allowed to add entries?
> This could be useful, for example, to distinguish your test releases,
> with a git hash for TZDATA_VERSION and possibly ZIC_VERSION, and
> DISTRIBUTION eggert or https://github.com/eggert/tz or whatever you
> choose.
A git hash could be helpful in those situations. Actually, just add
TZDATA_GITHASH as a separate field.

On 2/9/17 2:59 PM, Arthur David Olson wrote:
> The tzid might be stored as a seemingly extraneous time zone
> abbreviation, presumably with magic characters ("TZID"?) prepended or
> appended for identification purposes. Other such information could be
> included using the same approach.
Would this [then not] require a format change? That could be a benefit
to this approach, if so.
> The fifteen "reserved for future use" bytes near the start of time
> zone binary files are too few for this purpose (take
> "America/New_York"--and cue Henny Youngman).
Sounds like *that* future isn’t here, yet.

So there are about three approaches proposed to add this information.
Would such a version bump (if needed) require consumers to upgrade?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/tz/attachments/20170209/835d83ae/signature-0001.asc>

More information about the tz mailing list