Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data

[Ken Murchison <[e-mail]>]

Hi Lester,


On 12/10/2014 02:17 PM, Lester Caine wrote:
> On 10/12/14 18:55, Ken Murchison wrote:
>> On 12/10/2014 01:34 PM, Lester Caine wrote:
>>> On 10/12/14 17:51, Tim Parenti wrote:
>>>> I do agree that, given the intended use of tzdist and the intended speed
>>>> of update propagation, the potential hazard here is negligible.
>>> Apparently a lot of ISP's cache pages when they read them, and do not
>>> necessarily update them even if the source page changed. That caching
>>> may even be the browser on your computer! The 'potential hazard' is far
>>> from negligible!
>> Section 4.1.4 gives recommendations on the interval for servers and
>> clients to poll for updates.  If a client or server caches data for
>> longer than this before updating and users start missing meetings, the
>> users will stop using those clients and servers.  This is an
>> implementation problem, not a protocol problem.
> The protocol needs to be reliable and version is needed to plug this
> hole, and also then solves the historic archive problem.


Can you please explain how version plugs this hole?  I'm obviously 
missing your point.



>> If short term changes to published TZ data occur within these polling
>> windows, a version number won't solve the problem anyways. And even if
>> the short term changes are published outside of this window, there is no
>> guarantee that a primary server will be updated by an admin outside of
>> the polling window, so again, a version doesn't solve the problem
>> (unless you expect client to know what the expected version should be
>> via some OOB mechanism).
> THAT is the point ...
> When I publish a diary of events I have to add the name of the publisher
> of the TZ data I've used along with the version of data. That is then
> fixed and anybody accessing the diary can also access the TZ data used
> to create it. If one of the archive services freezes a copy of the pages
> then when ever they are looked at the user knows what data is needed to
> view it. If a user has a copy of the diary cached locally, and then
> finds that the 'latest' TZ version has changed they can easily assess if
> it affects anything they are looking at.


Maybe I'm just being thick, but why would I care what TZ data was used 
when events were published?  All I care about is what UTC offset was in 
effect at the exact instant of the event.  The most recent version of TZ 
data should always have the correct offsets, at least back as far as 
1970.  This should be the case regardless of the publisher.  If this 
isn't the case for TZ data moving forward, then people will stop using 
publishers of incorrect data.

If I invite multi-national colleagues to a conference call today using 
IANA 2014j TZ data, and at some point in the future I want to know when 
our call was, I should be able to use IANA 2020a or whatever to find 
out.  I shouldn't need to dig up a copy of 2014j.

The historic case that you mention (and possible use of incorrect data?) 
still seems like an extension to base tzdist to me.



-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University