[tz] [Patch] Make it slightly easier to parse tzdata

[Lester Caine]

On 02/11/14 08:41, Brian Inglis wrote:
> On 2014-11-01 16:35, random832 at fastmail.us wrote:
>> On Sat, Nov 1, 2014, at 16:24, Paul Eggert wrote:
>>> Brian Inglis wrote:
>>>> This would require a tradeoff between the compiled sizes of the
>>>> decompressors on your platform and the compressed data:
>>>>    94K tz.tar.xz
>>>
>>> We can shrink it even further than that, as follows:
>>
>> This requires embedding zic, though. I got the impression his post was
>> about compressing the compiled zoneinfo files (which are, after all,
>> what is required by the library functions)
> 
> He said he was unable to use zic and zoneinfo, so was talking about
> simplifying the source data to run against his Python parser, which
> could not handle constructs like last weekday of month, or 24.00 time.
> 
> If he does that, he is reverting the data to an earlier state that did
> not properly reflect the DST rules, loses the benefit of using the
> widely distributed and tested code and data, has to maintain his own
> patches against the distributed source, and his weak parser, which may
> have other bugs in handling the existing source data.
> 
> The alternative as others have pointed out is to find some way to use
> zic precompiled binary data.
> 
> Many other projects have chosen to use compressed binary archive formats:
> that approach may meet his unstated needs better, would be generally useful
> in the embedded space, and for network updates to similar devices.
> That approach could be added to the source code as an alternative to the
> standard hosted directory structure, and justify adding another compressed
> binary archive to the public distribution.

It is probably worth adding into that nice summary that iCalandar has
it's own method of describing rules and the tzdist discussions are based
on transforming tz data into THAT format before transmission, which
since they are not then capable of being transformed BACK into a tz rule
set makes a lot of existing code obsolete anyway? Paul - I have my own
reasons for wanting to maintain the existing tz rules after
transmission, but is this another one dictating that a proper
transparent transmission format is a requirement earlier rather than later?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk