[tz] Version in zoneinfo files?
stephen.goudge at petards.com
Mon Feb 13 10:39:51 UTC 2017
> -----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
> On Thu, Feb 09, 2017 at 17:37:53 -0800, Paul Eggert wrote:
> > On 02/09/2017 04:44 PM, Steven R. Loomis wrote:
> > >>>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?
> > Not in some installations. Android, I think, does not create filenames
> > like "America/New_York". More important, these names are not part of
> > the format now, and standardizing them in the format would increase
> > the likelihood of causing political irritations. And
> 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.
> Nathan Stratton Treadway - nathanst at ontko.com - Mid-Atlantic region
> Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
> GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID:
> Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
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
Senior Software Engineer
Tyne & Wear
T +44 (0) 191 420 3015
F +44 (0) 191 420 3030
This email has been scanned by Petards. The service is powered by Symantec MessageLabs Email AntiVirus.cloud
This email has been sent from Petards Group plc or a member of the Petards group of companies. The information in this email is confidential and/or privileged. It is intended solely for the use of the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any review, dissemination, disclosure, alteration, printing, circulation or transmission of this e-mail and/or any file or attachment transmitted with it, is prohibited and may be unlawful.
Petards Group plc is registered in England & Wales. Company No. 2990100
More information about the tz