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

[Lester Caine <[e-mail]>]

On 17/12/14 00:21, Doug Royer wrote:
>>> That point is valid, however as soon as the data is saved on the
>>> tzdist-server, and the first fetch is performed, is it not just as
>>> likely
>>> that it would trigger a everything is out of date when they compare
>>> it to
>>> 'nothing authoritative known about this TZID yet - so get it' ?
>>
>> OK, so when a list action changedsince is done we need to make sure of
>> the following:
>>
>> 1) The server only reports a time zone as changed if the underlying
>> data or meta-data (other than version id) has changed.
> 
> Trying to make sure I understand this:
> 
> The very first time a tzdist aware application or OS asks a
> tzdist-service, everything will appear to have changed - correct?
> So a changedsince makes no sense as the very first query to a tzdist,
> for each unique client - correct?

Unless a particular version is already pre-loaded ... in which case
tzdist just picks up from that version. Once we have a reliable archive
of versions.

>> 2) The server always reports the latest versions now in use for each
>> publisher.
> 
> Great, for my purposes thats all I need.

For a large majority of people once they have a set of data for their
area's of interest nothing will ever change. It is only a small number
of TZid's that will change, although Russia's recent revision is an
example of what can happen and other countries make short term political
decisions. The race problem that THOSE users need to be aware of is one
where they have 'latest', but the diary they are looking at has yet to
be updated to that version! Yes eventually things will catch up, but it
MAY be that 'the organisers' are not even aware there has been a change
over night and now need to make a decision. A message from SOMEONE that
there is a potential problem could assist if the organisers are
themselves travelling between locations at the time? This is the very
black hole that tzdist should be chartered to secure. We do have a few
examples of predicted DST transitions which simply did not happen, which
is something that even tzdist would have a problem with, but at least
tzdist would allow prompt correction of that problem, something which is
not currently practical. The need for tzdist is to publish the changes
... the base data is available anyway.

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