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

Lester Caine 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
>>> 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?
> 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
> queried.

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
> subtleties?

There are still ongoing discussions on how to combine for example tz
rules with additional historic material, but that may well not make the
first release.

> 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 mailing list