Thanks to Bradley White in <http://mm.icann.org/pipermail/tz/2017-February/024814.html> / <CAGb2eRP7oT3FpTvJCL=gZDX=VS3=5aiu0GTWT4xUpM-y-x5K8g@mail.gmail.com> for pointing me to this thread <http://mm.icann.org/pipermail/tz/2015-October/022807.html> 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? Thanks, -s