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

[Lester Caine <[e-mail]>]

On 16/12/14 19:58, Cyrus Daboo wrote:
>> I am thus inclined to have a mandatory version number. Although there are
>> alternative ways to do/think. I would like to see if there are any strong
>> opposition to this. Please send you opinion. I wish we find consensus
>> by/during the phone call.
> 
> As I proposed before I want to see the version number be part of the
> meta-data associated with the time zone data - i.e., part of the list
> action response. I don't want to see it in the time zone data due to the
> fact that, with the current manner in which IANA tz data is "tagged"
> with a version, the entire set of time zones would be marked as changed.

The same problem applies to the current TZ distribution process. One
gets a complete set of data every time and then have to work back
through to see if ANY of your live data needs looking at and perhaps
updating. That is the main reason I'm looking for a process that DOES
only return the changeset rather than a complete dataset.

If one has nothing cached, then one needs a full set of data. Once one
has a local cache running doing a list/changedsince for a later version
only has to return what has changed. This is no different to what would
have to happen anyway in the server. It would have to build the
changeset between the old and new version in order to provide the sub-set.

> I believe providing that information as meta-data is the right thing to
> do and gives clients/applications/protocols all the information they
> need to manage version discrepancies if that is something that is an
> issue for them. That does not preclude the possibility of using version
> ids that the publisher attaches to time zone data in the time zone data
> itself, if the publisher chooses to do that.

The whole point here is to provide some consistency and while there may
be more than one data provider, consistent use of the base TZ data set
is another charter point?

> As for how the version information is stored and used - that should be
> left solely up to the applications using the time zone data.

That is a given. The only problem with the statement is that there are
several consumers other than iCalendar apps that rely on the current
data format how ever it stored. Looking at a single data version is
relatively easy, it's the ongoing process of calculating the change set
each time new data is available. I can see that randomly adding changes
as they become available may seem an easy way of publishing updates, but
it's that very process that makes the management of historic material
almost impossible.

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