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

Tim Parenti <tim@timtimeonline.com> Wed, 10 December 2014 17:51 UTC

Return-Path: <tim@timtimeonline.com>
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 C99E21A8781 for <tzdist@ietfa.amsl.com>; Wed, 10 Dec 2014 09:51:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.198
X-Spam-Level:
X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no
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 pQPGiP3rjAFL for <tzdist@ietfa.amsl.com>; Wed, 10 Dec 2014 09:51:54 -0800 (PST)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B9C1A7017 for <tzdist@ietf.org>; Wed, 10 Dec 2014 09:51:54 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id k15so2301332qaq.38 for <tzdist@ietf.org>; Wed, 10 Dec 2014 09:51:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Lqd/l6G1VmSLZnfpvHjDj/MRYetSJPd8vRA0QiOl0Lo=; b=PIvisVgF5wXDAYRilixDOi4qaC/Fi1p+cMRMMjH9n0eofUFLJw7QGU/eV11orpoRWK gx1OIo9DzteY92HijJQ/W4X9K97siuAlsp4FNxvco+1gNRalrVVQvBwfVEQ1+Xb3bWw5 u3wp47bM/mffUt4WkQNqOBwyg+QX1k7fuhpQI3iLjN+hZEhlAlRR0DpWMbGyNDWet+f3 Vv68B5fjJ3/Ov5QkyGOoAgE3BXRgaJTaulomcoXpGAxsKWytA6WsaGf8PgcyoVRKjy3G 8XFxDt+ACuavmUykvq/sP4SQ4T2EGbhxRf0WK0WSEyvgmPoO4AMIBuJXbChz8PaBA+By uSsQ==
X-Gm-Message-State: ALoCoQkX+KxsJT4jGoVBcpqn0KQApeQCjfP86PI3UFOXMhN8z4J8UlLK9LEPznPukk4EyQXfztP2
X-Received: by 10.140.94.117 with SMTP id f108mr10486628qge.50.1418233913389; Wed, 10 Dec 2014 09:51:53 -0800 (PST)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com. [209.85.216.171]) by mx.google.com with ESMTPSA id s19sm4854002qay.6.2014.12.10.09.51.52 for <tzdist@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 09:51:52 -0800 (PST)
Received: by mail-qc0-f171.google.com with SMTP id r5so2543357qcx.16 for <tzdist@ietf.org>; Wed, 10 Dec 2014 09:51:51 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.104.12 with SMTP id z12mr10028465qge.75.1418233911945; Wed, 10 Dec 2014 09:51:51 -0800 (PST)
Received: by 10.229.86.195 with HTTP; Wed, 10 Dec 2014 09:51:51 -0800 (PST)
In-Reply-To: <676B23282D9F7F1DCE6A54C7@caldav.corp.apple.com>
References: <059.5da79d7c9d394e20e3c22513cfe04c33@tools.ietf.org> <074.141a9388d35dbdf392fcdf7384321e4e@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> <676B23282D9F7F1DCE6A54C7@caldav.corp.apple.com>
Date: Wed, 10 Dec 2014 12:51:51 -0500
Message-ID: <CAFpi07x79gJLEBWmpxWv7V13CiwmeKGy7bwS1=+ukp-sKmwFxA@mail.gmail.com>
From: Tim Parenti <tim@timtimeonline.com>
To: Cyrus Daboo <cyrus@daboo.name>
Content-Type: multipart/alternative; boundary="001a1134f7c887ce050509e05044"
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/yNe1e34xaxOov04FHXUt4bzvOQg
Cc: Time Zone Data Distribution Service <tzdist@ietf.org>
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:51:56 -0000

On 10 December 2014 at 12:42, Cyrus Daboo <cyrus@daboo.name> wrote:

> --On December 10, 2014 at 12:32:47 PM -0500 Tim Parenti <
> tim@timtimeonline.com> 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?
>>
>>
> No need. Users will congregate to tzdist servers that provide accurate and
> timely updates because those will ensure they don't miss meetings due to
> time zone data mismatches or update latencies. That is one of the key
> benefits of tzdist - it frees the user from depending on slow OS updates
> and gives them an independent path to a reliable system.
>

I do agree that, given the intended use of tzdist and the intended speed of
update propagation, the potential hazard here is negligible.


> Now maybe I am being far too optimistic in how I think tzdist will
> actually be used, but we are giving everyone the opportunity to have
> something they can rely on and that does not have to involve all kinds of
> "version reconciliation" between clients which would otherwise vastly
> complicate the clients themselves (and which I doubt most client authors
> will bother with given that they have typically not done so to date in the
> existing unreliable environment).
>

I think this is a laudable goal.  That said, if we move toward allowing
arbitrary versions of data to be queried, I would see no harm in putting
the applicable version number in responses, to assist clients, and indeed
that would help to shift these kinds of (minor) issues away from the tzdist
protocol itself.  (I don't currently have a strong opinion on the larger
question.)

--
Tim Parenti