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

Lester Caine <lester@lsces.co.uk> Fri, 12 December 2014 21:21 UTC

Return-Path: <lester@lsces.co.uk>
X-Original-To: tzdist@ietfa.amsl.com
Delivered-To: tzdist@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFB81A8A17 for <tzdist@ietfa.amsl.com>; Fri, 12 Dec 2014 13:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zymEvGcdb843 for <tzdist@ietfa.amsl.com>; Fri, 12 Dec 2014 13:21:49 -0800 (PST)
Received: from mail4.serversure.net (mail4-2.serversure.net [217.147.176.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296FE1A89EB for <tzdist@ietf.org>; Fri, 12 Dec 2014 13:21:49 -0800 (PST)
Received: (qmail 17270 invoked by uid 89); 12 Dec 2014 21:21:47 -0000
Received: by simscan 1.3.1 ppid: 17261, pid: 17266, t: 0.0968s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677
Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.178.188.220) by mail4.serversure.net with ESMTPA; 12 Dec 2014 21:21:47 -0000
Message-ID: <548B5C6A.6050707@lsces.co.uk>
Date: Fri, 12 Dec 2014 21:21:46 +0000
From: Lester Caine <lester@lsces.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Time Zone Data Distribution Service <tzdist@ietf.org>
References: <059.5da79d7c9d394e20e3c22513cfe04c33@tools.ietf.org> <676B23282D9F7F1DCE6A54C7@caldav.corp.apple.com> <CAFpi07x79gJLEBWmpxWv7V13CiwmeKGy7bwS1=+ukp-sKmwFxA@mail.gmail.com> <5488921B.8020900@lsces.co.uk> <5488973F.7050400@andrew.cmu.edu> <54889C39.1080103@lsces.co.uk> <D2BE5C3BFE11019ECF4BEF62@caldav.corp.apple.com> <5488A6E6.8050903@lsces.co.uk> <CADC+-gTiyJ4QHZT6m3je9M9-ifSELnSWgmgy7iXSWNS+p8pthg@mail.gmail.com> <5488C0EA.8090505@lsces.co.uk> <CADC+-gTgckSe1ca6Sai6RguQid=ReM7bH6K8+dVVFm-YfbpFbA@mail.gmail.com> <5488DA56.2090306@lsces.co.uk> <CADC+-gQN=Qb2y8M-bHnPzMcK8r=xUG-seQ7XzvZwwcWsHpHnBQ@mail.gmail.com> <54895986.6060806@lsces.co.uk> <5489CA90.1070307@gmail.com> <35BC5886C9A58F866E8A46A8@caldav.corp.apple.com> <5489D9F7.3080207@gmail.com> <D196D63077FEC1B090DF7C86@caldav.corp.apple.com> <5489F79E.4080909@gmail.com> <548A0485.3010202@lsces.co.uk> <548A141A.6060806@gmail.com> <548A4B23.7030209@lsces.co.uk> <548B3884.1050300@gmail.com>
In-Reply-To: <548B3884.1050300@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/oBxCFhlwr4RlnPRJhiElitKgVXs
Subject: Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data
X-BeenThere: tzdist@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <tzdist.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tzdist>, <mailto:tzdist-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tzdist/>
List-Post: <mailto:tzdist@ietf.org>
List-Help: <mailto:tzdist-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tzdist>, <mailto:tzdist-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Dec 2014 21:21:55 -0000

On 12/12/14 18:48, Doug Royer wrote:
> If your *not* sending the VTIMEZONE with the VEVENT,  then there is no
> last-modified to see or compare to. Your just guessing and hoping the
> other end is using the latest version.

All that is needed with the event is a version tag ... a single extra
element. This then assumes VTIMEZONE is populated by other means - such
as tzdist :)

> Many of my customers have off-line secure systems and the updates to the
> TZ database will be manual. An outsize URL *only* is useless to me. I am
> sure I am not the only one that will need to work with mostly off-line
> systems.

This is precisely what is happening with the bulk of the  historical
archive material. Once one has a version tag, everything can be
processed off-line. The only reason for accessing the on-line service is
to establish if the latest version has changed from your off-line cache,
and you only need to do anything if that update affects a TZid that is
currently being used by you. If all your material is in an area where
there is no active change from year to year then essentially nothing
changes for you. If you find that a problem has arisen tzdist provides
an indication of the problem, but humans may have to decide what changes
are required. My MAIN reason for wanting a managed version tracking
process is exactly because I may well be working off-line for hours
while travelling, and then using a different tzdist server at my
destination ... which has to mirror the data I already have cached and
will advise if I need to update the cached material. A system reliant on
a permanent synchronised update process does not work especially if
'changedsince' is not consistent between different servers. One can't
assume that the original server continues to be accessible when moving
between different access mechanisms?

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