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

[Lester Caine <[e-mail]>]

On 29/11/14 13:55, Daniel Migault wrote:
> So I am trying to summarize the use we are addressing. Suppose we are
> planning an event at date D0 using UTC as a reference, for people in
> different time zone. This event is planned at date D1. For one of the
> participant, its time zone has been updated between D0 and D1. This
> updates results in having D1 (UTC) to move from D1_LOCAL_0 before the
> change occurs to D1_LOCAL_1 after the change.
> 
> If one receives the event indicating that D1 is D1_LOCAL_0. I should be
> able to say, this local time has been derived from an tz that is not
> relevant at D1, so so the actual event is at D1. Is that the or at least
> a use case we intend to address?

I need someone more 'proficient' with Islamic Time to fill in some of
the fine detail, but the problem arises when a meeting scheduled for say
10AM local time in a day or so's time is published with a UTC time of X
but then there is a revision to the local time due to the observed
events which may start or stop Daylight Saving differently to expected
so the local time moves and hour relative to UTC. That a video linkup
will now happen differently was the problem I have had in practice, and
the local time of the event SHOULD have been changed since the link was
booked on the UTC time! Once you know the problem has arisen then there
are several ways to resolve it but all involve change one time or another.

The same problem will arise at short notice if a published DST
transition does not ACTUALLY happen. We have had a couple of examples of
this recently, and these might affect events longer into the future!

> If so, using version could indicate which 'tz' has been used. For my
> information how do we specify, the reference time? In our example, I
> chose UTC, but, if we had chosen local time of the changing time zone,
> then D1 would have been changed for almost all other time zones.

The event is published using the current TZ data, and we have to publish
the version information with the event data. When a delegate looks at
the announcement for the event the local time advertised will be using a
particular publishers set of TZID's and the current version of that
data. By the time the delegate is looking at the event timetable, the
latest TZ data may already be 'current+1' as so the data presented may
be wrong. He then needs to know that for his particular TZID there is a
discrepancy between the data he is looking at and the CURRENT situation
on the ground. HOW the problem is to be fixed will depend on just what
can be moved ... the local time activity retaining the UTC time, or does
the UTC time need to change to reflect the new local time. *WE* can't
answer that via tzdist, but by proper use of the version we can identify
that there are two possible times now for this event and that the
delegate needs to perhaps update their data for the event to match the
LATEST version of the tz data or if no later version of event data is
available - contact the organizers.

> If the mentioned use case is correct, then we may have to look at:
>     1) whether we have consensus that a version should be added
I do not see how you can avoid a race condition without it?

>     2) How version can be inserted in the URL model
In order TO avoid the race condition a user must be able to access the
data that matches that used to publish some event. Secondary to that
this fixes all of the historic material since as new versions are
published, all of the historic data is retained, and there may be
several versions of tz between publishing an event calendar to the event
happening ... changedsince can not be used to ascertain if any of the
material has changed ... you either check out an updated version of the
event calendar with a later version of tz - if available, or
alternatively one can check if there is a difference between the version
used to publish the data and the current data.

>     3) What are the version speciifc operation. Maybe we should be able
> to ask for the lastest version?
What happens when the latest version has a short notice change in DST
data which is not yet handled in the material one is looking at? In
particular, LOCAL delegates may well be aware that there is some
uncertainty when an event will happen, but the people using UTC time are
generally totally unaware and in the current state of flux on many DST
transitions, one does need to know that there has been a change rather
than simply assuming that the 'latest' version is being used for the
data we are looking at! The local time of an event may well change if a
global link up has been booked based on UTC time.

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