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

Lester Caine <lester@lsces.co.uk> Wed, 10 December 2014 18:11 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 B2EE11A1A31 for <tzdist@ietfa.amsl.com>; Wed, 10 Dec 2014 10:11:36 -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 pb0bKye82xZ8 for <tzdist@ietfa.amsl.com>; Wed, 10 Dec 2014 10:11:35 -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 034121A00BD for <tzdist@ietf.org>; Wed, 10 Dec 2014 10:11:34 -0800 (PST)
Received: (qmail 25278 invoked by uid 89); 10 Dec 2014 18:11:33 -0000
Received: by simscan 1.3.1 ppid: 25271, pid: 25275, t: 0.0895s 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; 10 Dec 2014 18:11:33 -0000
Message-ID: <54888CD5.60507@lsces.co.uk>
Date: Wed, 10 Dec 2014 18:11:33 +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: tzdist@ietf.org
References: <059.5da79d7c9d394e20e3c22513cfe04c33@tools.ietf.org> <544A88D8.7010108@lsces.co.uk> <544A9442.5010805@cs.ucla.edu> <544AA116.8030003@lsces.co.uk> <CAAGevbVBacBaX0syYc5eOVvO72N2UjCOJN-quPPGekOf7yzNqw@mail.gmail.com> <544ADFB7.80705@lsces.co.uk> <CADZyTkmK89hSUBqdrrjJUwTccn+NrW+gJB81RJqDkGZTO=TuEA@mail.gmail.com> <5454FE3D.60801@lsces.co.uk> <CADZyTkmfZ9BHU-1oYvCr-bfKEBA2B92EDUgbVYC_kQ1CDUQJ3w@mail.gmail.com> <5475BD47.7040900@lsces.co.uk> <CADZyTkmviNBkM-C_-5Gq+RruUu7R7P9bwKCvg7+1nGnx+NzJ_Q@mail.gmail.com> <54788334.3010604@lsces.co.uk> <CADZyTkn92ZXnf0MOJjFH59eAYG_Bnu5FZ0x1UcoUq27MkRKZzA@mail.gmail.com> <5479E42A.8080306@lsces.co.uk> <CADZyTk=aVNFmoR1GA+w_xU7+-28Rnb-TJY4uT-jVOU4jdC1yKg@mail.gmail.com> <CACzrW9D=wZi1VvCiGa-4kwbKAyHMs6rduF6+cKA0Nn0gshm+sQ@mail.gmail.com> <54877E06.5020409@lsces.co.uk> <39981BA759F3923868CCFBD3@caldav.corp.apple.com> <54888249.9080607@lsces.co.uk> <A45D37B17AB7F8FA019BAAC0@caldav.corp.apple.com>
In-Reply-To: <A45D37B17AB7F8FA019BAAC0@caldav.corp.apple.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/yGijIsIyw68BfxH0VmdqJYEUuaA
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: Wed, 10 Dec 2014 18:11:37 -0000

On 10/12/14 17:50, Cyrus Daboo wrote:
> As per my reply to Tim, users will opt to use tzdist servers that do
> provide timely and accurate updates if they start missing meetings
> because the ones they are using (or their reliance on just OS updates)
> fail them.

I am assuming that the only source is tzdist ... and by mirroring TZ
exactly as is I have accurate material to work with. Do you even accept
that there IS a providential race condition where data is published and
cached prior to a short notice change and when a user looks up this data
a few hours later there is the potential for miss information? It is
BECAUSE we have already had problems due to this very problem that I'm
trying to avoid it being an inherent flaw in anything replacing what we
currently use. Designing this race condition into tzdist is something
that strongly object to.

Probably 90% of users don't even need tzdist since their offset will
never change, but for some it is important to know that the data they
are looking at in a diary may well change tomorrow. Some of that
information is hidden in notes in TZ, but often it is not until a change
happens that we know that dates we had have a problem. That the diary
publisher should be flagged by a "changedsince" indication identifying a
problem allows the diary to be updated promptly, but that requires that
every cached copy also gets updated, and it's THAT part of the
distribution process that 'version' ensures the integrity off? Simply
assuming every copy matches is not a safe assumption?

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