IETF Logo Mail Archive

Re: [Tzdist] LMT transition

Eliot Lear <lear@cisco.com> Wed, 20 August 2014 20:41 UTC

Return-Path: <lear@cisco.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 2F8381A874F for <tzdist@ietfa.amsl.com>; Wed, 20 Aug 2014 13:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level:
X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 wYcf7Zzfg34n for <tzdist@ietfa.amsl.com>; Wed, 20 Aug 2014 13:41:39 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A0D1A874D for <tzdist@ietf.org>; Wed, 20 Aug 2014 13:41:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1731; q=dns/txt; s=iport; t=1408567298; x=1409776898; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=88c8liM6gPJj1cRHBsEufeVNkcS2bEHFUGOR7Iet36E=; b=ZUAeUt9J8/FkwCqO92gDwIOfTTgKK0ttJ2vYDBX/Bwi/pLl1/0/cukSz aCN0AcPGcg6xIVISn9o6+S9NZb3ZY5sXaTEOe0RFZl+ENp3v55rd5X6BY BbUMfYygqymO6+RgyHYbBJsk66Fv1bIzfZsJ746X5pqs1oULHcPpIsfFG A=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqIEAL4G9VOtJssW/2dsb2JhbABaDocl0SoBgSd3hAQBAQQjVRELDgoJFgsCAgkDAgECAUUGAQwIAQGIPq0WlToXj1OCeYFTAQSTJYFKh1WHLY1dgxtEO4J+AQEB
X-IronPort-AV: E=Sophos;i="5.01,904,1400025600"; d="asc'?scan'208";a="143699569"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 20 Aug 2014 20:41:36 +0000
Received: from [10.61.91.44] (ams3-vpn-dhcp6957.cisco.com [10.61.91.44]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7KKfa4L031206; Wed, 20 Aug 2014 20:41:36 GMT
Message-ID: <53F507FF.7030007@cisco.com>
Date: Wed, 20 Aug 2014 22:41:35 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ken Murchison <murch@andrew.cmu.edu>, tzdist@ietf.org
References: <53F25B6B.4000502@lsces.co.uk> <7758C165EA7A17FFBD3029E1@caldav.corp.apple.com> <53F4E4A8.2020603@cs.ucla.edu> <53F4E98C.4020608@gmail.com> <53F4FB12.7080909@lsces.co.uk> <53F4FD4D.9000205@andrew.cmu.edu>
In-Reply-To: <53F4FD4D.9000205@andrew.cmu.edu>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="gCln9lx9j31kHbPxStX9RXHWgbujbR4sM"
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/AIfDHHILEJckebsEY3yvx3JXSws
Subject: Re: [Tzdist] LMT transition
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, 20 Aug 2014 20:41:40 -0000

On 8/20/14, 9:55 PM, Ken Murchison wrote:
>
> Assuming that I'm understanding the issue correctly, if such a flag
> ever appears in the IANA timezone data (or some other source), a
> mapping for that flag to a new or existing iCalendar property for
> inclusion in VTIMEZONE can certainly be made.  But I think such a
> mapping is outside the charter of this WG.

The content of the database itself – perhaps modulo any necessary
encoding – probably should be outside the scope of this group, if we can
avoid it.  This means that draft-douglass-timezone-service needs to be
careful to minimize the use of semantic searches that might use fields
in the database.  Right now my reading is that you are on the correct
side of that line, at the moment.

Eliot

v2.23.0 | Report a Bug | By Email