On 2/13/17 2:39 AM, Goudge, Stephen wrote:
-----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Nathan Stratton Treadway Sent: 10 February 2017 03:54 To: tz@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.
-s