[tz] Version in zoneinfo files?

Steven R. Loomis srl at icu-project.org
Mon Feb 13 16:31:29 UTC 2017

On 2/13/17 2:39 AM, Goudge, Stephen wrote:
>> -----Original Message-----
>> From: tz-bounces at iana.org [mailto:tz-bounces at iana.org] On Behalf Of
>> Nathan Stratton Treadway
>> Sent: 10 February 2017 03:54
>> To: tz at iana.org
>> Subject: Re: [tz] Version in zoneinfo files?
>> On Thu, Feb 09, 2017 at 17:59:23 -0500, Arthur David Olson wrote:
>>> 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
>> I am pretty sure it wouldn't be the best solution to the overall set of goals
>> being discussed in this thread, but just in case it inspires better ideas I'll
>> throw the following thought into the ring:
>> It occured to me that a way to avoid putting these zone names into the data
>> file itself yet still have the data file be "uniquely" identified would be to have
>> some process (hash?) come up with a unique, shorter-than-15-byte
>> identifier for each zone, which could then be placed in in the existing
>> "reserved for future use" field in the data file.
> FWIW For a number of years I have been using a simple scheme where we have a short integer that is used as a TZ id - in an embedded environment, we record data samples with a UTC timestamp plus this id number. When the data is displayed we use a simple table, indexed directly by the short integer, to look up the full-length TZ name and display the local time when & where the data was recorded.
> There should be enough space in the "reserved for future use" fields to store a short and then provide the mapping table as a separate file.
> I've mentioned this idea a couple of times in the past, e.g. http://mm.icann.org/pipermail/tz/2013-March/018707.html and, if there was interest, would tidy up the table & code and make it available. The big problem with this scheme is that there are problems when zones are deleted - as happened in tzdata2011m when Europe/Tiraspol vanished
This makes some sense, however as far as goals go, it solves one problem
but adds another: Locating the table of mappings. The flip side is
having a new file for implementations to deal with.


More information about the tz mailing list