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

[Lester Caine <[e-mail]>]

On 11/12/14 19:59, Doug Royer wrote:
> How does updating your view of what you think organizers TZ should be
> help? You would then be relying on the attendees to notice the organizer
> TZ is incorrect and informing the organizer manually. If no one notices
> or manually notifies the organizer (iTIP or phone) - you still are not
> on the same time slot. It could be that no one would have a clue until
> the event starts.

That is exactly what happens today :(

Currently there is no reliable base to work off. As far as I am
concerned, different devices may well currently not have the same set of
offsets for a group of events. tzdist is at least a staring point in
providing a base that we can work from, and I would expect a single base
publisher to be used rather than the current disjointed standards.

For genealogical data it HAS to be a fully un-truncated set of material,
and this is an area where each version of TZ currently adds a growing
number of fixes to historic material - if that is actually included in
the published set.

For current calendars we now have a fairly reliable tracking of changes
happening via the TZ list, and in most cases while these changes have
not yet been published in a formal release, the information is available
to be passed down the chain. One would hope that a local venue might
update their clients that there is a problem with a booking but it
simply does not happen, so a more organised method is needed to make
people aware when something changes. It is a requirement that tzdist
provides timely notification of changes and there is little problem in
carrying that out, but USING that data is reliant on client systems
updating what they have published equally promptly. Using a simple
version tag allows every third party user to be advised if there is a
potential problem, and YES they may then ring the organisers to clarify
what is going to happen - and that may be the first the organiser knows
of the change! This can only happen if the third party knows that the
data is presented using the old version while there has been a change to
that data in the mean time. Be that a six month old calendar that has
now been messed up because subsequently a country has had a change of
government and DST has been changed drastically, or an astronomical
event has change the next weeks offsets from the initial assumption.

Does it matter if some data is wrong ... YES ... That the TZ data we are
using today may in fact be inaccurate is a fact, either going forward as
DST changes are currently assumptions, and going backwards as more and
more archival material is being uncovered to fill in the known gaps in
the backzone data. So we need to know what data was used at the time it
was used, and then we can review the material and update it as required.
This currently fails simply because we now have no idea just what data
was used to build the original data set.

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