Re: [Tzdist] tzdist examples

[Lester Caine <[e-mail]>]

On 29/12/14 13:48, Ken Murchison wrote:
> On 12/26/2014 12:45 PM, Daniel Migault wrote:
>> My current understanding is that there is not a strong support for
>> keeping "changedsince" in the current spec, and that it could be left
>> for future work.
> 
> I wouldn't go that far.
> 
> I agree with Cyrus that changedsince is important to reduce the size of
> the list response for clients looking to update the full set of time
> zones.  This is especially true now that we have added versioning
> information to the list response thus growing its size.
> 
> Regardless of whether a client chooses to use changedsince, this
> functionality is fairly trivial to implement in a server, and 3 existing
> servers have already done so.  In fact, this functionality has been
> interop tested doing server to server time zone updates.

While we are not concerned with 'how' a server does it's job, to get
around the existing problems with historic/archival data, moving away
from a 'single binary dump' of the TZ data to a versioned view of each
TZid allows many of the current holes to be plugged, and changedsince
does simply come out in the wash ... along with triggers to flag that
particular TZid's HAVE changed.

Part of the problem is that the TZ data is not reliant on any of the
current tz code, but it is that code which is being used to dictate what
should now happen, and that will not produce the 'right' result! An
interim solution that continues to support the current essentially
broken model will fit in fine, but providing a base for a proper
overhaul moving forward should be the aim here?

One point in relation to using 'seconds' based dates is of cause
identifying just what date range the calendar being used is truncated
to. Viewing 5000+ year old artefacts on Malta one needs a calendar that
will be accurate from -3500 BC right the way through with a clean
framework over the whole Roman pre and post BC period. TZ need only be
valid for the last three or four hundred years, but ideally one does not
then change the clock/calendar at some point, which is why a seconds
base is a potential problem, which using a different base avoids.

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