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

[Lester Caine <[e-mail]>]

On 01/11/14 13:14, Daniel Migault wrote:
> Given the new URL format discussed in Issue #29. A version has been
> specified. Can you let us know if it solves the historical data issue
> completely. If it does not solve it completely, could you expose the
> appropriated extensions that would solve this issue?

Introducing a correctly managed version number in the first instance
fixes the race problem created by the current 4.2.2 and 4.2.3 !
A set of published calendar data will somehow identify the version of
tzdist data it is currently using, and a new client can request that tz
data set at the same time as accessing the calendar data. If the tzdist
source has been updated ( say overnight ) but the calendar data has yet
to be revised, then the client can identify potential problems for
themselves while the current process WOULD return a later tzdist set
than that actually being used in the calendar.

Historic material just gets automatically tidied up in the base fix at
the expense of maintaining a growing set of versions over time. As has
been said, the process needs to work from day one and is not something
that can be added in 10 years time :(

> From the call conference, I thought that this issue would be solved by
> introducing redirections to tzids. That is if I need the complete time
> zone related to Paris from let say 1875 to 2056, I would be returned a list:
>  [{utc_start:start_time0,
>    utc_stop:stop_time0,
>    tzid: tzid0}
>    ....
>    {utc_start:start_timeN,
>    utc_stop:stop_timeN,
>    tzid: tzidN}
> 
> where tzid is one of the Time zones we are distributing. I might be
> completely wrong. Suppose i am not, I am not also sure that such a
> mechanisms will be described in the current service distribution. It
> might be another document. However, the current service distribution
> should clearly make that possible.

THAT summarises where I think I've got to myself quite nicely! expand
can return usable data across essentially 'rule' boundaries, but I'm not
sure if iCalendar can handle a switch of rule sets perhaps 'mid rule' so
we get say two summertime offsets following one another rather than a
clean summertime/wintertime sequence?  I currently envisage tzidN as
perhaps a current generic rule set, while tzid0 may simply be a location
identifier rather than defining a full set of rules. THAT is why I'm
thinking the prettyURL (That is what RESTFUL style urls WAS called)
field IS 'rule', and this composite set becomes a 'zone' or 'location' ...

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