Re: [Tzdist] Next step

Cyrus Daboo <cyrus@daboo.name> Mon, 19 October 2015 19:21 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 0668E1B2C46 for <tzdist@ietfa.amsl.com>; Mon, 19 Oct 2015 12:21:14 -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 jh5VMPOkgrFg for <tzdist@ietfa.amsl.com>; Mon, 19 Oct 2015 12:21:12 -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 682081B2C3B for <tzdist@ietf.org>; Mon, 19 Oct 2015 12:21:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id AB458231AD51; Mon, 19 Oct 2015 15:21:11 -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 19iBLARim54d; Mon, 19 Oct 2015 15:21:11 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id C239E231AD46; Mon, 19 Oct 2015 15:21:10 -0400 (EDT)
Date: Mon, 19 Oct 2015 15:21:08 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Doug Royer <douglasroyer@gmail.com>, tzdist@ietf.org
Message-ID: <D44D1D4F0B3A210577A4B5BF@caldav.corp.apple.com>
In-Reply-To: <5625402D.9070409@gmail.com>
References: <CADZyTkmO_PcfWTw-36U_6vo=EuDAnAmvUo6nvPZjkHjb_ALPSQ@mail.gmail.com> <40285_1445262970_t9JDu8BA043191_50DBD330DB51FDFC0C3E86D4@cyrus.local> <5624FAC4.5030008@andrew.cmu.edu> <B38549591D4FFBE5A83BF0BD@cyrus.local> <56253CCB.6010602@gmail.com> <316D3AAC6E4A5336C1784897@caldav.corp.apple.com> <5625402D.9070409@gmail.com>
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=1702
Archived-At: <http://mailarchive.ietf.org/arch/msg/tzdist/vjjIQRFmvksB6Dz0sAohcj8pooE>
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: Mon, 19 Oct 2015 19:21:14 -0000

Hi Doug,

--On October 19, 2015 at 1:10:37 PM -0600 Doug Royer 
<douglasroyer@gmail.com>; wrote:

>> It is true that there are already web services that do that kind of
>> thing (see e.g.,
>> <http://www.geonames.org/export/web-services.html#timezone>). The
>> question is whether that would be valuable for a client to do directly
>> along side tzdist - or would we just let them rely on their existing
>> "date-time/timezone" picker UI.
>>
>
> Postal codes don't always map to time zones. When you live way out in
> the country, the postal code can be more than 20 miles away from the
> city with the same name.  The postal code is designed to route
> snail-mail to your home, not define your physical location.
>
> I know postal codes can cross time zones, city boundaries and perhaps
> county boundaries, not aware of any state boundary issue. I picked the
> Wells Nevada example for that reason. Some rural residents that live out
> of the city limits have Wells zip codes because it is the nearest post
> office. And they are not in the same time zone as Wells NV.
>
> That would make the database a real mess to keep up to date.

Does not use postal codes, uses lat/long. Look at the "Timezone" service at 
the bottom of that page.

Also, I would expect any service like this to be smart about returning 
multiple TZIDs for the case where the lat/long is close to a boundary 
between different time zones or is in an area of "dispute" where multiple 
tzids might be in effect.

Anyway, the point right now is to gauge whether there is any interest in 
supporting a feature like this in tzdist. I am sure we can come up with 
something that works reasonably well if we want to...

-- 
Cyrus Daboo