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

[Lester Caine <[e-mail]>]

On 11/12/14 22:00, Doug Royer wrote:
> For a PUBLISH event:
> 
>     Using the existing method:
> 
>         Only one CUA is really in play as other CUAs must periodically
> check for updates
>         (REFRESH or reload a file).
Please point me to some RFC for 'CUA' ... all may calendar material is
published using TZ as distributed via PHP, and it is ensuring that
clients have the same version of TZ that I'm working towards currently.

>         If the organizer CUA does not see the TZ update or update the TZ
> data in the event,
>         things are busted and there is no documented way to solve the problem.

VTIMEZONE has a 'last-modified' entry which would match the timestamp of
a published version of TZ data. As has been said, the vast majority of
published events that timestamp would be 'day one' and offsets will
never change. It is only a small number of events that may be a problem
and even without tzdist we can document a way to manage that problem.

>         Attendee CUAs could detect there may be a problem because the TZ
> data is different.

I'm having trouble working out how an Attendee identifies the TZid being
used looking at iTIP spec. Like many older standards, the basic
functions had timezone information patched in and are not ideal for
planing events that happen concurrently in several locations, but I am
sure that if the Attendee has the right information, then the version
from 'last-modified' will allow checking that an unpublished change may
apply. Just as re-coding TZ information into VTIMEZONE format looses
some useful material, other conversions seem to be going on here, and
I'm sure the same comparisons can be made in this application area again
even without tzdist as a distribution method.

>         If an attendee CUA ignores the old TZ data in the event, they
> may or might not be on time.

If the event is published as a local time only and they arrive at the
local time then things are probably OK. The problem is not with
individual events, but with ones where the same event is also happening
in another timezone and SHOULD happen at the same time. THAT is what
iCalendar does not handle safely currently? Planning based on a UTC time
base with only displayed information showing a local view is not
something that seemed to work using iCalendar processes? But it was a
good few years back I ruled out iCalendar as a base for UTC normalized
event planning. At that time for transport timetables cross Europe.

>         Existing CUA PUBLISHed events will are compliant with the new methods.
> 
>         Existing compliant CUAs need no code changes to work now.
> 
>         As CUAs are updated, they can add code to check servers for new TZ data.

I feel we need to properly identify the various holes in the current
processes and either accept they will not be fixed, or agree a process
which if used can prevent them happening. If people do not want to use
that process then fine. Like the useless time offset provided in a
browser packet, some things have been broken a long time so why bother
fixing them?

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