Re: [Tzdist] Create and distribution process of events with TZ data.

[Lester Caine <[e-mail]>]

On 11/12/14 17:33, Doug Royer wrote:
> 
> There seem to be two separate issues in the latest discussions.
> 
>    (1) Distribution of TZ data.
> 
>    (2) Create/Update event change notifications that may include TZ
> changes.
> 
> As to Distribution (#1) of updated TZ data:
> 
>     That is one of the points to this mailing list and I am still
> getting up to date.
>     I still do not see the need for version information - still reading
> old posts.

You do not use any material on the internet which was publish in the
past and for which TZ data has now changed? The majority of users will
never be bothered but once tzdist is being used as a distribution
source, then one HAS to know what version was used to create the
material being looked at. This data will not be updated every time there
is an update, and the material may well involve areas of data that even
today is still being corrected and expanded.

> As to the Create/Update (#2) it already has a mechanism - iTIP and my
> comments on that are:
> 
> I would think the achievable process would be to first have at event
> creation time the
> organizers user agent make an attempt to get the latest up to date
> version of time zone and
> distribute all or part of that TZ data with the event (or group of events).
> 
> Its not going to be possible for many small devices to track TZ versions
> or compute differences
> and update the user to a schedule change resulting from TZ data changes.
> Explaining how
> to do that, doing that correctly, is going to be a pain. If too many
> fail at this, inaccurately computed
> TZ change computations is just as useless as not sharing any TZ data.

Embedded clock devices will only be tracking one or perhaps two
timezones, and only need to know that their next transition has changed.
ETag or changedsince can certainly handle that since they are already in
sync and if not, then only the latest data is needed.

> I don't think anyone wants every CUA when powered up to contact a TZ
> authority and look for updates,
> then do all those recalculations on every event to determine if there
> are any changes the user needs
> to see. This would be DNS level connections with larger data packets.
> 
> Which is why I think it is the event creators responsibility to get the
> up to date information
> and if it happens to not be up to date at least everyone will be late or
> early :-)
> 
> When the organizer/CUA notices a significant TZ change has occurred,
> then then it iTIP handles
> the redistribution of scheduled events. No need for a new mechanism.
> When the
> organizer, or organizers CUA notices a TZ change, a person or automated
> process can
> re-PUBLISH or  schedule the new updates with the new TZ data just as
> they do now.
> Any iTIP compliant CUA can already handle this.

Race hazard!
Yes you can pray that the diary you are looking at is correct, but while
it may not be a very common event, DST offsets do change at short notice
and it's ONLY this type of race hazard we need to protect against. Once
again ... if a schedule is published and over night the up-coming change
is amended, then a simple use of the version mechanism which IS needed
for all historic data also protects against the race hazard of published
data not yet having been updated to reflect the new situation.

The current system is broken for many reasons. tzdist is still
perpetuating some of those problems such as different sets of TZid's
from different publishers, but this is an existing problem which can be
protected against. If you can explain how using 'changedsince' can
achieve the same protection then I would have less of a problem, but
that certainly can't be used to address the historic data management.

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