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

[Cyrus Daboo <[e-mail]>]

Hi Lester,

--On December 13, 2014 at 9:20:56 AM +0000 Lester Caine 
<[e-mail]> wrote:

> This is why for me avoiding contaminating the TZ rule set with
> conversions to VTIMEZONE's different format IS important. I have no
> problem with a third party server producing VTIMEZONE converted TZ data
> in much the same way as tzurl already seems to do? The FIRST requirement
> of tzdist should be to ensure that the core data used for that matches
> every body else's ... a step that the charter totally scraps. But as
> long as one can access *A* clean and reliable source AND be able to
> identify the version of it that was used for a particular job, then I
> will be happy. It's the fact that currently when I look at data from
> 200x the TZ data is an unknown even if the publisher claims a particular
> TZ version.

Well I have made several proposals on how to address this. Let's try 
again...

Paul has suggested that "changedsince" should actually represent as version 
identifier (if I understood his comments correctly). Is it sufficient to do 
this:

1) Replace the "dtstamp" member of the list action response with a 
"version" member that represents the version details for the entire set of 
time zone data returned in the list action? Note that the default /zones 
action may aggregate data from multiple publishers in which case the 
version would be specific to the aggregator not to the publisher. However, 
if the /publisher/versions uri were used then the "version" value would be 
specific to the referenced publisher.

2) The new "version" member value could then be used as the value for 
"changedsince" for clients to get back just those time zones that have 
changed since the specified version.

3) Open issue: does the version value belong in the time zone data returned 
by the server. My big concern about this is that I would prefer it if 
clients did not have to download an entire time zone just to find out that 
the only difference is a change in the version. That is what would happen 
if the client only used ETag and If-None-Match with HTTP. This impacts one 
of the use cases that you championed - namely a simple, fixed, device such 
as a building wall clock that only ever cares about one time zone. Do we 
want all such devices to download the (potentially large) time zone data 
when the only thing that has changed is the version?

What I would like to do is get some consensus on (1) and (2) right now, and 
then come up with ways of addressing (3) that satisfy both your concerns 
about version integrity and my concerns about protocol efficiency (which 
ultimately translate into scaleability concerns if one is going to have a 
service supporting possibly millions of devices).

-- 
Cyrus Daboo