[tz] [EXT] Re: Uruguay out of DST

[Paul_Koning at dell.com]

> On Jul 15, 2015, at 11:37 PM, Brian Inglis <Brian.Inglis at SystematicSW.ab.ca> wrote:
> 
> On 2015-07-15 08:54, Paul_Koning at Dell.com wrote:
>> 
>>> On Jul 14, 2015, at 4:56 PM, Brian Inglis <Brian.Inglis at SystematicSW.ab.ca> wrote:
>>> 
>>>> ...
>>> 
>>> TZdist seems to require a server which tracks changes at zone and impacted
>>> date time range levels (implying also dependencies on rules and aliases).
>>> The server would have to pull apart the current zoneinfo source or
>>> binary files and track when changes happened and what ranges were impacted.
>>> The server returns zone info within changed and impacted date time ranges
>>> of interest to the client in iCalendar, XML, or JSON formats, where the
>>> client then has to decide how to apply these to its data base.
>>> 
>>> This would allow automated updating for calendar applications but not
>>> obviously for system zoneinfo data, which is the topic of interest,
>>> and would require an iCalendar parser hooked up to part of the zic
>>> compiler.
>> 
>> I don’t understand why you make those assumptions.
>> tzdist is just a protocol for conveying timezone data.
>> It’s clearly possible to feed that data into the “system zoneinfo data”, that’s purely a local matter.
> 
> Aren't protocols developed based on "rough consensus and running code"?
> That normally requires demonstrating protocol interoperability between a couple each of sources and sinks.
> Where are the demo servers and clients available?

“rough consensus and running code” applies once you get far enough along.  In particular it is required to get a protocol approved for its second and subsequent stages of standardization.  But while rough consensus is required, you don’t require running code, or demonstrated interoperability, just to get the original spec out the door.

Currently there is a draft protocol spec.  People can start implementing from that (and I assume they are doing exactly that).  A client prototype can talk to a server prototype and do something useful with the data it gets.  One thing it could do, if it wants to, is generate system zoneinfo files from what it learns.  Or it can do something entirely different.  What I meant is: the spec says how client and server communicate; it does not say or constrain what the client does with the data it receives.  

You said it would “not obviously [allow updating] for system zoneinfo data, which is the topic of interest”.  I agree that it’s of significant interest; I do not agree that there is any difficulty in updating zoneinfo data.  Not unless the draft protocol omits necessary information, in which case that’s a protocol bug that can easily be fixed once identified.

	paul