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

[Brian Inglis]

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.

Requested via REST URI parameters and data returned in JSON or VCALENDAR
format, with selectivity as optional server capabilities which may be queried.

Basic capabilities could be satisfied by a thin shim around zdump in your
favourite web language.

Does that appear to be a reasonable summary or have I missed some subtleties?

It was unclear to me if MS could be a publisher of Windows "zones"?
-- 
Take care. Thanks, Brian Inglis