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

Lester Caine <lester@lsces.co.uk> Wed, 10 December 2014 17:52 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 E99981A894C for <tzdist@ietfa.amsl.com>; Wed, 10 Dec 2014 09:52:41 -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 0tY3CgIu2PT0 for <tzdist@ietfa.amsl.com>; Wed, 10 Dec 2014 09:52:31 -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 B70BF1A8781 for <tzdist@ietf.org>; Wed, 10 Dec 2014 09:52:30 -0800 (PST)
Received: (qmail 23124 invoked by uid 89); 10 Dec 2014 17:52:29 -0000
Received: by simscan 1.3.1 ppid: 23118, pid: 23121, t: 0.0922s 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 17:52:28 -0000
Message-ID: <5488885C.1090107@lsces.co.uk>
Date: Wed, 10 Dec 2014 17:52:28 +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> <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> <CAFpi07z8NauUZ5aBqqg9sXDsmSA+hG4HuZNDkLe7fnk=mg4wgA@mail.gmail.com>
In-Reply-To: <CAFpi07z8NauUZ5aBqqg9sXDsmSA+hG4HuZNDkLe7fnk=mg4wgA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/hF8Vfgroliy03dpmqUcIklPl4Fc
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 17:52:42 -0000

On 10/12/14 17:32, Tim Parenti wrote:
> Where I /do/ see a potential race hazard is in defining exactly what
> value "changedsince" takes on.  Is it the time at which a tzdist
> publisher receives the new data, or begins distributing it, even if it
> was technically available to them hours or days beforehand?  Or should
> this date be fixed at the source (e.g., tz release timestamps) and
> propagate somehow throughout the tzdist system?

It has been stated already that "changedsince" is managed by the server
and so even for the same publisher a different server will give a
different value. So that can't be used to identify WHICH "changedsince"
matrial was used by the information source since it is more than likely
using a different source? IF "changedsince" was the published date for a
version ... but it's being able to access an older version that is the
problem here.

Of cause if we WERE defining a single set of data with a single update
sequence then things would be a little easier, and personally I will
rely on TZ and it's well defined versions for my own source of data to
publish. But no doubt other sources will keep their own slightly
different views of things.

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