Re: [Tzdist] Next step

Cyrus Daboo <cyrus@daboo.name> Tue, 20 October 2015 01:29 UTC

Return-Path: <cyrus@daboo.name>
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 5B7BA1B2C7B for <tzdist@ietfa.amsl.com>; Mon, 19 Oct 2015 18:29:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YdMo70aAnwpr for <tzdist@ietfa.amsl.com>; Mon, 19 Oct 2015 18:29:24 -0700 (PDT)
Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45ED91B2A98 for <tzdist@ietf.org>; Mon, 19 Oct 2015 18:29:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 45E312324BD7; Mon, 19 Oct 2015 21:29:23 -0400 (EDT)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_d2zIEf7U5q; Mon, 19 Oct 2015 21:29:23 -0400 (EDT)
Received: from [17.45.162.214] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id EDA3F2324BCC; Mon, 19 Oct 2015 21:29:21 -0400 (EDT)
Date: Mon, 19 Oct 2015 21:29:20 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Paul Eggert <eggert@cs.ucla.edu>, Eliot Lear <lear@cisco.com>, Daniel Migault <daniel.migault@ericsson.com>, Time Zone Data Distribution Service <tzdist@ietf.org>
Message-ID: <BF8D641CBC49495AE8950B8E@cyrus.local>
In-Reply-To: <56259231.1030704@cs.ucla.edu>
References: <CADZyTkmO_PcfWTw-36U_6vo=EuDAnAmvUo6nvPZjkHjb_ALPSQ@mail.gmail.com> <50DBD330DB51FDFC0C3E86D4@cyrus.local> <5625323F.4060102@cisco.com> <56259231.1030704@cs.ucla.edu>
X-Mailer: Mulberry/4.1.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=1186
Archived-At: <http://mailarchive.ietf.org/arch/msg/tzdist/OTsKq1uR-vkGW2iTnaGIL-UuQT0>
Cc: Barry Leiba <barryleiba@computer.org>, tzdist-chairs@tools.ietf.org
Subject: Re: [Tzdist] Next step
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 20 Oct 2015 01:29:25 -0000

Hi Paul,

--On October 19, 2015 at 6:00:33 PM -0700 Paul Eggert <eggert@cs.ucla.edu>; 
wrote:

>> So you are talking about/var/share/zoneinfo/..., etc?  In other words,
>> tzfile.5 in the distribution?
>
> That's my understanding of the proposal, yes. Basically, tzfile.5 on
> wheels. The format is already defined and is widely used; all that's
> needed is to RFC-ize it. (Yes, I know, "all" is sometimes a big word....)

Right!

> Perhaps there's some call for JSON too, I don't know.

I think the tricky part about tzfile is dealing with the endian and 
32/64-bit differences. I am assuming we would need to serve up all possible 
variants of those if we used the binary format as is. So we could end up 
with, e.g., application/zoneinfo-be-32, application/zoneinfo-le-32, 
application/zoneinfo-be-64, application/zoneinfo-le-64 etc, which seems a 
little clumsy.

With a JSON abstraction of the binary format, clients would need a simple 
tool to convert JSON to the right binary format for their platform, but 
that should be a small amount of code. Obviously the JSON data would be 
larger than the binary equivalent, which might be another downside of using 
it.

-- 
Cyrus Daboo