Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data
Lester Caine <lester@lsces.co.uk> Wed, 10 December 2014 19:17 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 040FD1A8796 for <tzdist@ietfa.amsl.com>; Wed, 10 Dec 2014 11:17:24 -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 VLvFZAla-npH for <tzdist@ietfa.amsl.com>; Wed, 10 Dec 2014 11:17:16 -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 ADEE21A6F6F for <tzdist@ietf.org>; Wed, 10 Dec 2014 11:17:15 -0800 (PST)
Received: (qmail 32397 invoked by uid 89); 10 Dec 2014 19:17:14 -0000
Received: by simscan 1.3.1 ppid: 32390, pid: 32394, t: 0.1107s 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 19:17:13 -0000
Message-ID: <54889C39.1080103@lsces.co.uk>
Date: Wed, 10 Dec 2014 19:17:13 +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> <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> <CAFpi07z8NauUZ5aBqqg9sXDsmSA+hG4HuZNDkLe7fnk=mg4wgA@mail.gmail.com> <676B23282D9F7F1DCE6A54C7@caldav.corp.apple.com> <CAFpi07x79gJLEBWmpxWv7V13CiwmeKGy7bwS1=+ukp-sKmwFxA@mail.gmail.com> <5488921B.8020900@lsces.co.uk> <5488973F.7050400@andrew.cmu.edu>
In-Reply-To: <5488973F.7050400@andrew.cmu.edu>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/YZ2KQ4koeaqP6k7zlvbxzOJGxlY
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 19:17:24 -0000
On 10/12/14 18:55, Ken Murchison wrote: > On 12/10/2014 01:34 PM, Lester Caine wrote: >> On 10/12/14 17:51, Tim Parenti wrote: >>> I do agree that, given the intended use of tzdist and the intended speed >>> of update propagation, the potential hazard here is negligible. >> Apparently a lot of ISP's cache pages when they read them, and do not >> necessarily update them even if the source page changed. That caching >> may even be the browser on your computer! The 'potential hazard' is far >> from negligible! > > Section 4.1.4 gives recommendations on the interval for servers and > clients to poll for updates. If a client or server caches data for > longer than this before updating and users start missing meetings, the > users will stop using those clients and servers. This is an > implementation problem, not a protocol problem. The protocol needs to be reliable and version is needed to plug this hole, and also then solves the historic archive problem. > If short term changes to published TZ data occur within these polling > windows, a version number won't solve the problem anyways. And even if > the short term changes are published outside of this window, there is no > guarantee that a primary server will be updated by an admin outside of > the polling window, so again, a version doesn't solve the problem > (unless you expect client to know what the expected version should be > via some OOB mechanism). THAT is the point ... When I publish a diary of events I have to add the name of the publisher of the TZ data I've used along with the version of data. That is then fixed and anybody accessing the diary can also access the TZ data used to create it. If one of the archive services freezes a copy of the pages then when ever they are looked at the user knows what data is needed to view it. If a user has a copy of the diary cached locally, and then finds that the 'latest' TZ version has changed they can easily assess if it affects anything they are looking at. > Some of this depends on the definition of "short term change". If > "short term" means that new TZ data gets published less than a day prior > to a change, then I don't see how tzdist can be expected to handle > this. If "short term" means a few days, then I would fully expect that > well-behaved admins would update primary servers ASAP and that > well-behaved secondary servers and client would gets updates during a > polling interval that takes place prior to the impending time zone change. I am currently receiving diaries for next year published using todays TZ version. I have a copy of each TZ version so can view the data, but if some of that data changes in the new year by what mechanism do I check that the iary has been updated on the source site? I check the version of TZ used ... This has nothing to do with keeping a CURRENT set of data up to date, but rather to ensure that the data being used matches that used when material using dates and times normalized to UTC is published. -- 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
- [Tzdist] [tzdist] #32 (service): managing histori… tzdist issue tracker
- Re: [Tzdist] [tzdist] #32 (service): managing his… tzdist issue tracker
- Re: [Tzdist] [tzdist] #32 (service): managing his… Tobias Conradi
- Re: [Tzdist] [tzdist] #32 (service): managing his… Lester Caine
- Re: [Tzdist] [tzdist] #32 (service): managing his… Tobias Conradi
- Re: [Tzdist] [tzdist] #32 (service): managing his… Paul Eggert
- Re: [Tzdist] [tzdist] #32 (service): managing his… Tobias Conradi
- Re: [Tzdist] [tzdist] #32 (service): managing his… Lester Caine
- Re: [Tzdist] [tzdist] #32 (service): managing his… Tobias Conradi
- Re: [Tzdist] [tzdist] #32 (service): managing his… Lester Caine
- Re: [Tzdist] [tzdist] #32 (service): managing his… Daniel Migault
- Re: [Tzdist] [tzdist] #32 (service): managing his… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Daniel Migault
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Daniel Migault
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Stephen Colebourne
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Eliot Lear
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Tim Parenti
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Tim Parenti
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Ken Murchison
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Ken Murchison
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Mike Douglass
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Martin Burnicki
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Eliot Lear
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Daniel Migault
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Paul Eggert
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Paul Eggert
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Paul Eggert
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Paul Eggert
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Paul Eggert
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Daniel Migault
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Paul Eggert
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Doug Royer
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Cyrus Daboo
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] [tzdist] #32 (service): managing his… tzdist issue tracker
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Daniel Migault
- Re: [Tzdist] Fwd: [tzdist] #32 (service): managin… Lester Caine
- Re: [Tzdist] [tzdist] #32 (service): managing his… tzdist issue tracker
- Re: [Tzdist] [tzdist] #32 (service): managing his… Lester Caine