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

[Stephen Colebourne <[e-mail]>]

Just to note that I am in favour of including an optional version
number in the spec using the previously discussed /versions/{version}
approach.

Stephen


On 5 December 2014 at 21:35, Daniel Migault <[e-mail]> 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.
>
> BR,
> Daniel
>
> On Sat, Nov 29, 2014 at 4:20 PM, Lester Caine <[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
>>
>> _______________________________________________
>> Tzdist mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tzdist
>
>
>
>
> --
> Daniel Migault
> Orange Labs -- Security
> [phone]
>
> _______________________________________________
> Tzdist mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tzdist
>