Re: [Tzdist] tzdist examples

[Lester Caine <[e-mail]>]

On 05/01/15 14:43, Daniel Migault wrote:
> To my knowledge, the only remaining issue is Issue # 32 on
> history/changedsince. Cyrus needs some more feed backs from the WG to
> determine whether changedsince should stay or should go. Please provide
> your feed back by Thursday so Cyrus can provide the last version of the
> draft. Most likely, this draft will go to WGLC as all issues have been
> addressed.

Am back in front of a proper desktop, but still working through 'paid'
traffic.

I still need to review a number of points, but I think this is still
being made a lot more complicated than it needs to be!

The whole problem is simply one of identifying that the information
being used is no longer valid. With the current OS based distribution,
applications do not get information that TZ has changed, so a service
that can flag 'changedsince' make sense. What also fails at the moment
is that the data provided via the OS updates is of variable quality. Be
that due to factors like binary data without leapseconds, or truncated
data where we have no idea just what the truncation is.

Create a reliable source that can be identified - publisher - add a
simple version mechanism - version - and we can at least have a little
more security that information normalized with a particular
publisher/version can be used reliably. Add the information that the
data is using version x but we now have x+1 which affects only a very
small subset of TZid's then one can establish if any of the data being
used MAY be affected. The BULK of the TZ traffic on tzdist need only be
diff sets of material.

Embedded devices and other services which don't need a full TZ dataset
will either use expand, or perhaps a single TZ dataset. If there is a
version change but it does not affect that TZid, the used 'version'
simply gets updated, while if the TZid IS affected the device has a
trigger to do something, but exactly what is up to the device. As a
minimum it would download the correct data ... and update version.

Over time as a publisher provides updates, each historic version
snapshot is simply a natural part of the process. As material is
archived a mechanism that records the publisher/version ensures that the
matching view of the TZ (and leapsecond) data can be recalled. It is not
putting any undue load on the server, simply providing a reliable way of
establishing the state of TZ when the data was created, and creating a
diff between the current version and the archived one will also come out
in the wash as it will only contain those TZid records that have
changed. Getting this process working from day one gets around the
current agro off having to reverse engineer the data from the new
complete data dump and make life very much easier for the multitude of
devices that currently have no means of even knowing a change has occurred.

Binary leapsecond correct data is simply a different wrapper around the
packet of TZid data. All of the embedded devices I'm currently looking
at do not use a seconds based calendar and it would be interesting to
know just how many calendar systems are day/time based rather than
'second'. There has been a debate in other lists over replacing the
second epoch based system with something a little more practical that
does not simply truncate the calendar at different points, and I know of
no archival system that uses seconds based calendars, using day/time
based binary data instead.

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