[tz] Version identification (was Re: Downstream use of 2021c)

Steven R. Loomis srl295 at gmail.com
Fri Oct 8 16:14:40 UTC 2021

> El oct. 7, 2021, a las 6:12 p. m., Paul Eggert via tz <tz at iana.org> escribió:
> On 10/7/21 15:54, Alan Mintz via tz wrote:
>> there are "fifteen bytes containing zeros reserved for future use" starting at the 6th byte of the tzfile(5) binary format. Perhaps some of that could be used to carry the version of the source data? If downstream mods add their own suffix,
> That's been proposed before. Unfortunately, it's likely that version strings would exceed 15 bytes in length, given downstream needs. For example, the tzdata package on my workstation is named "tzdata-2021b-1.fc34.noarch" and I've seen longer.
> Also, as a rule I've found that putting a version number into every file (or every line of every file) to be overkill. It's generally better to have at most one version number per thing versioned.

In implementations, the single file ( such as America/Chicago ) is often only available by itself, with no context.  /etc/localtime may  be a hard link to somewhere, or simply copied from some random location.
So yes, having the version on every single binary file would be the most useful, given the way these files are used.

I also proposed that the files contain their ids internally (America/Chicago) for the same reason. Perhaps there’s some way to recode this information into 120 bits.


More information about the tz mailing list