[tz] [Patch] Make it slightly easier to parse tzdata
lester at lsces.co.uk
Tue Nov 4 09:51:52 UTC 2014
On 04/11/14 02:40, Brian Inglis wrote:
> On 2014-11-02 02:08, Lester Caine wrote:
>> On 02/11/14 08:41, Brian Inglis wrote:
>>> Many other projects have chosen to use compressed binary archive
>>> that approach may meet his unstated needs better, would be generally
>>> 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
>>> 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
> Looked at what tzdist now proposes.
> Seems to want to keep (one or more?) change date(s) per zone and provide
> roughly equivalent output to zdump, returning what if anything was affected
> since the last zone change time, since a user specified change time (last
> user update timestamp), or current data, for a given UTC time range (like
> "zdump -c" but to the second), or the whole historical range of the zone.
Two basic modes ...
One provides the rules for a zone ... currently only VTIMEZONE
documented. tz generic rules could be passed via this method, but no
means of combining rules to make a complete zone set.
Second provides an 'extract' as a series of events in JSON format which
can be used for simple devices that just need the next couple of
What is currently missing is accessing a known state of data so one can
synchronise what is read from tzdist and what was used for the calendar
you want to use it with.
> Requested via REST URI parameters and data returned in JSON or VCALENDAR
> format, with selectivity as optional server capabilities which may be
The URI based format has not yet been incorporated in the draft, just
waiting for the current lock down on IETF before that can be uploaded.
> Basic capabilities could be satisfied by a thin shim around zdump in your
> favourite web language.
The draft proposal allows for expansion in any direction. It is only
concerned with 'transmitting data' ... not what is actually transmitted.
> Does that appear to be a reasonable summary or have I missed some
There are still ongoing discussions on how to combine for example tz
rules with additional historic material, but that may well not make the
> It was unclear to me if MS could be a publisher of Windows "zones"?
The charter for the tzdist group specifically has no jurisdiction about
who published the data, what TZID's they use, or even if a TZID from two
different sources produces the same data :(
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
More information about the tz