Re: [Tzdist] Next step

Tim Parenti <> Tue, 20 October 2015 18:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 919B21A9125 for <>; Tue, 20 Oct 2015 11:28:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 mIsFSiTU3OnP for <>; Tue, 20 Oct 2015 11:28:15 -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 DEE461A9234 for <>; Tue, 20 Oct 2015 11:27:33 -0700 (PDT)
Received: by iodv82 with SMTP id v82so31863768iod.0 for <>; Tue, 20 Oct 2015 11:27:32 -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=9aAhouvBr6zZSGh1bCnx1n1uQ5sFl5CEz5iJzq0itew=; b=iqcpEPzXtm+6CLkb1NabSP6L29GEZpx8rB0KTWfFaNnlQfeJJ9hlkCFJ2kyzK7IGlH qaefV8DkNMbCbjnPkhax4gjdnw9BSJe5SjAoj/AWn+XL6iWhPkY0YTqbedE9rrWFOvMQ ePCZud2l3jFR+cybyHXBScdGIWn2gbfol2vBV/nBUxV7SNoaMCaaI8qURdT+MZjdW4PF dFclAL//gqTEPENfMTnwiXKZi6r09wAQLXTJRD9KjB4FHYHtYFsSip3AxC0o10mxZ/cc YGA5tZEmIIXTQMQoPOprsMBzrbv/0KgIoFnLNZ6pXcvWTo/M0HRvFSzm6qrXUmXMjogN 7Sow==
X-Gm-Message-State: ALoCoQmQNmFLnb/GyI04TYnTCDiZ1uH6f8uez0rp26ZgVB15MSzvQK4h4ZdOb2PL4zarQqDMajkq
X-Received: by with SMTP id j16mr6249516ioj.167.1445365652258; Tue, 20 Oct 2015 11:27:32 -0700 (PDT)
Received: from ( []) by with ESMTPSA id x142sm1968575iod.31.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2015 11:27:31 -0700 (PDT)
Received: by igbkq10 with SMTP id kq10so81449708igb.0 for <>; Tue, 20 Oct 2015 11:27:30 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id nq2mr5546053igb.19.1445365650271; Tue, 20 Oct 2015 11:27:30 -0700 (PDT)
Received: by with HTTP; Tue, 20 Oct 2015 11:27:30 -0700 (PDT)
In-Reply-To: <>
References: <> <40285_1445262970_t9JDu8BA043191_50DBD330DB51FDFC0C3E86D4@cyrus.local> <> <B38549591D4FFBE5A83BF0BD@cyrus.local> <> <> <>
Date: Tue, 20 Oct 2015 14:27:30 -0400
Message-ID: <>
From: Tim Parenti <>
To: Lester Caine <>
Content-Type: multipart/alternative; boundary=047d7b10cd6b27b8bd05228d6a83
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: Tue, 20 Oct 2015 18:28:26 -0000

On 20 October 2015 at 02:34, Lester Caine <>; wrote:

> areas do move from one timezone to another outside of the TZ
> framework

Yes, normal borders and border disputes aside, this type of thing is
particularly non-obvious.  For example, when India and Bangladesh exchanged
several enclaves
this past August, nominally, the borders between Asia/Kolkata (UTC+5:30)
and Asia/Dhaka (UTC+6:00) moved.  Did the clocks in those areas change?
Technically, it would seem so, but the truth on the ground is probably much
more complicated, and it's nominally outside the scope of tz.

In a different type of case, the presence of historical zones could cause
needless complications in calendaring.  For example, my main calendars here
in Pittsburgh all use America/New_York, but for some reason my mobile
provider tells my phone that it's in America/Detroit.  So when I view any
events created on my phone from a web interface, I'm warned to be cautious
since I'm viewing an event in a different time zone, which although
technically true, is mildly annoying considering that there haven't been
any differences between those two zones since 1975.  I'd imagine for
someone, e.g., in Toledo, Ohio using a lot of locations near the border
between America/New_York and America/Detroit, this would be similarly
aggravating, especially since they probably don't think about that as a
time zone border.

Implementations in this area might endeavor to distinguish between "borders
that potentially matter" and "borders that definitely don't matter", which
seems a tenuous distinction.

Tim Parenti