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

[Lester Caine <[e-mail]>]

On 10/12/14 20:34, Ken Murchison wrote:
> Don't know if you intended to take this off-list, but I left it as such.
Should have been on list ;)

> On 12/10/2014 02:57 PM, Lester Caine wrote:
>> On 10/12/14 19:32, Ken Murchison wrote:
>>> Maybe I'm just being thick, but why would I care what TZ data was used
>>> when events were published?  All I care about is what UTC offset was in
>>> effect at the exact instant of the event.  The most recent version of TZ
>>> data should always have the correct offsets, at least back as far as
>>> 1970.  This should be the case regardless of the publisher.  If this
>>> isn't the case for TZ data moving forward, then people will stop using
>>> publishers of incorrect data.
>>>
>>> If I invite multi-national colleagues to a conference call today using
>>> IANA 2014j TZ data, and at some point in the future I want to know when
>>> our call was, I should be able to use IANA 2020a or whatever to find
>>> out.  I shouldn't need to dig up a copy of 2014j.
>>>
>>> The historic case that you mention (and possible use of incorrect data?)
>>> still seems like an extension to base tzdist to me.
>> PLEASE read the various posts on the race problem with some TZ offset
>> changes!
> 
> I have, and I understand the race.

>> Yes a large majority of users will not even know there is a problem, but
>> for a small number of cases, DST offsets are changed at short notice due
>> to astronomical observations. So a meeting may move an hour at short
>> notice. 2014j becomes 2014k and the change currently slowly limps out so
>> no one knows until they log in at 10am to see then end of the meeting
>> because it started an hour earlier. My own example had video links
>> booked against UTC times, so the local meeting time had to change
>> retaing the UTC bookings. If the published timetable was tagged with
>> 2014j and tzdist is now saying 2014k a client can at least flag the
>> difference and warn that something has to change!
> 
> As I stated earlier, if a change is so short notice as to not be able to
> propagate prior to an affected meeting, then neither versions nor
> timestamps will solve the issue.  In this case, I would expect the
> user(s) in the affected time zone to be aware of such an impending
> change and coordinate the times manually with other participants.

It is getting a change out faster that is the key to tzdist actually
working. I can see some servers providing additional versions of TZ data
which are geared to support problem locations, but as well as the short
notice changes, longer time frame changes to previously published TZ
offsets also create a race condition.

>> Some DST events are changing almost annually, so a longer term event
>> calendar may well see an update in a years time. My own meeting
>> calendars run into 2016 already and even the UK DST can't be relied on
>> being retained.
> 
> Understood, which is why the actual UTC offsets should be calculated by
> the consumer with current TZ data near the time of an event.
> As Mike Douglass posted, this is why CalDAV clients and servers, store
> the TZID with an event.  As you note, pre-calculating UTC offsets is
> going to result in incorrect future times in some cases.

An international event will have meetings at different local times in
different countries. This is why normalizing to UTC is important, and it
IS the normalizing using the TZ data at the time of publication which
will be used to book video links, rooms and the rest. CURRENTLY when the
local time changes there is nothing flagging the problem and so problems
arise. Simply using a new set of TZ data is what causes the problem,
where as the system should report that there IS a problem at least. It
can't provide a fix, but that there IS a conflict at least allows the
organisers to see that and decide on a solution, which would normally be
to change the local time of the meeting leaving the UTC times
unaffected, that is if the facilities are available. Again, longer term
events may be affected if an unexpected change to DST rules are made for
political reasons. Assuming that you are looking at current times on
what may be a cached copy of the timetable creates a bigger window for
the race condition.

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