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

[Lester Caine <[e-mail]>]

On 05/12/14 21:35, Daniel Migault wrote:
> Dear Friends and Colleague,
> 
> Please provide your opinion on adding a version number. I would like
> this issue to be solved soon so we can have text in the next version.

I'm still waiting for an explanation on how a version number can be avoided!

> On Sat, Nov 29, 2014 at 4:20 PM, Lester Caine <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     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