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

[Cyrus Daboo <[e-mail]>]

Hi Lester,

--On December 10, 2014 at 5:26:33 PM +0000 Lester Caine 
<[e-mail]> wrote:

> OK one way of making your system work is to INSIST that ever published
> dairy is always updated to the current data set for their publisher? Not
> going to work, it takes time to find that what was published now needs
> updating, and the material published may well already be cached around
> the network, so an update will take time to propagate.

As per my reply to Tim, users will opt to use tzdist servers that do 
provide timely and accurate updates if they start missing meetings because 
the ones they are using (or their reliance on just OS updates) fail them.

> Historic material archived today will tag the publisher and the version,
> and as long as in 10 years time the matching data can be recovered there
> is not a problem. But the same simple process provides the necessary
> security to CURRENT material since 'latest' may well not be the version
> used five minutes ago ...

So in ten years time the historians can just look at what data was current 
on the date of the event. They can also look and see if there was a time 
zone change prior to that time and use that to determine the accuracy of 
the actual time stamp (e.g., if the tzid being used was last changed one 
year prior to the event, then the probability of that event's actual time 
being correct is very high, if it was changed only a day or two before the 
event, then the probability is a lot lower, though if they know a reliable 
tzdist server was in use, then they can probably bump the probability up).

My key point here is that if version information really is important to the 
client, then they can insert that themselves from the data already provided 
by tzdist - e.g., include the actual URI for the tzdist data and the 
"primary-source" value from the /capabilities response, if the URI did not 
include /publisher or /versions segments.

-- 
Cyrus Daboo