Re: [Tzdist] Next step

Tim Parenti <> Mon, 19 October 2015 15:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4D3D11AC424 for <>; Mon, 19 Oct 2015 08:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.198
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pcq-NkRhW-Cn for <>; Mon, 19 Oct 2015 08:07:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C46E61ACD46 for <>; Mon, 19 Oct 2015 08:06:19 -0700 (PDT)
Received: by igbkq10 with SMTP id kq10so55535841igb.0 for <>; Mon, 19 Oct 2015 08:06:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MHXgLIC1gJx/pvXzh9v9mEW60V+G7w9WMVk0KdeFi0E=; b=cN35KUVeUKGPRz/gdB1OsH2CLKUEo8VUcMdeo4gVf/5RQrm1uUNqxbdd6I9yMD2zT+ vqxmc1R8QmvFVPonx/WG46Luy8Wl5oqKZka5qB77SJpR3mZ3kRdRuTI0vgq1lDbhBJzS o6uneAbf2E3HwHkZ0iMAPH6YLJJZcvBAOcnUSc1e9tU2FyMdYqqegtXPdJVzMFKSSiIc kQrkpf16Res3RI7lR4p6bo4j05taUJLEdAVkoJMj30NUdml2E3jFBnA8O8M2rGsCBLv3 Sv7PgQCSZ3wSYWyZLhIBDRifoFWC0W9EpFuqAqDWMouNljE7GLr30k2rnu3nzx3iPl4o uYfA==
X-Gm-Message-State: ALoCoQkcNxT9UfD1w9vSvMkO5R7yOoELcyhDXy9mDi83ZNgug1eAg2nOgJlGg8M9XAJoYYBjxuGY
X-Received: by with SMTP id i17mr17057778ioo.136.1445267179009; Mon, 19 Oct 2015 08:06:19 -0700 (PDT)
Received: from ( []) by with ESMTPSA id l80sm6162507iod.34.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 08:06:18 -0700 (PDT)
Received: by ioll68 with SMTP id l68so33443714iol.3 for <>; Mon, 19 Oct 2015 08:06:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id g5mr30677065ioj.23.1445267177159; Mon, 19 Oct 2015 08:06:17 -0700 (PDT)
Received: by with HTTP; Mon, 19 Oct 2015 08:06:17 -0700 (PDT)
In-Reply-To: <>
References: <> <40285_1445262970_t9JDu8BA043191_50DBD330DB51FDFC0C3E86D4@cyrus.local> <>
Date: Mon, 19 Oct 2015 11:06:17 -0400
Message-ID: <>
From: Tim Parenti <>
To: Ken Murchison <>
Content-Type: multipart/alternative; boundary=001a114214fab355ac0522767cfd
Archived-At: <>
Cc: Time Zone Data Distribution Service <>
Subject: Re: [Tzdist] Next step
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Oct 2015 15:07:51 -0000

On 19 October 2015 at 09:55, Cyrus Daboo <>; wrote:

> 1) Add a location->tzid mapping extension to the tzdist protocol. That
> ought to be a relatively trivial extension to define if there is interest.

+1 to the idea.

On 19 October 2015 at 10:14, Ken Murchison <>; wrote:

> Actually, would this be a mapping from something like "Pittsburgh, PA" ->
> "America/New_York", or from GPS coordinates to a tzid, or both?

Although both would be quite useful, mappings from location strings such as
"Pittsburgh, PA" to geographical coordinates such as 40.44,-79.95 are well
outside the scope of things timezone-related, and that is arguably a space
which is fairly well-serviced by existing APIs.  So I think
coordinates-to-timezone should be sufficient for us, but perhaps we would
want to develop a protocol for other useful mappings.

To be clear, this kind of "mapping" data (if you'll pardon the play on
words) is something the tz (Olson) project has explicitly avoided over the
years, due to the highly political nature of border disputes and the like.
Hopefully it is evident to most on this list that the mapping from location
to timezone is unequivocally NOT one-to-one, despite the appearance in most
cases that it is, but I'll hold off on specific examples unless/until the
WG decides we should explore this path.

Even so, for implementors, Eric Muller's maps at
are reasonably up-to-date (2013b) and may be a decent starting point for a
service seeking to provide this kind of data.

On 19 October 2015 at 09:55, Cyrus Daboo <>; wrote:

> 2) In conjunction with the IANA tzdb folks, define a media type that
> describes the "zoneinfo" file format (either a direct binary representation
> or, say, a JSON representation of that) so that tzdist servers can directly
> provide the zoneinfo file data that many OS's use.

If this is an offshoot from Ticket 34
<> ("should we include a
raw tzdb format media type?"), then +1 to this collaboration as well.

Tim Parenti