Re: IETF must use only UTC in its announcements (Was: Live Streaming of the IETF 88 Technical Plenary

Cyrus Daboo <> Wed, 30 October 2013 15:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8EB611E8199; Wed, 30 Oct 2013 08:24:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1bGzyOmwYC5A; Wed, 30 Oct 2013 08:24:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 980F811E824A; Wed, 30 Oct 2013 08:23:57 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A39450B294A; Wed, 30 Oct 2013 11:23:57 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r5wOdUNRMifd; Wed, 30 Oct 2013 11:23:56 -0400 (EDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id 1C3A250B293F; Wed, 30 Oct 2013 11:23:54 -0400 (EDT)
Date: Wed, 30 Oct 2013 08:23:22 -0700
From: Cyrus Daboo <>
To:, Eliot Lear <>
Subject: Re: IETF must use only UTC in its announcements (Was: Live Streaming of the IETF 88 Technical Plenary
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="2269"
Cc: Carsten Bormann <>, IETF Discuss <>, IETF-Calsify <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Oct 2013 15:24:06 -0000


--On October 30, 2013 at 7:52:55 AM -0700 wrote:

>> > Which argues for including the local time when the event will take
>> > place. If you want to mandate that the time also appear in UTC, great,
>> > but it's quite important that the local time also be there.
>> And local time should be normative to deal with such unforeseen
>> circumstances as a papal visit.  From the southamerica file in the TZ
>> database:
>> # From Daniel C. Sobral (1998-02-12):
>> # In 1997, the DS began on October 6. The stated reason was that
>> # because international television networks ignored Brazil's policy on
>> # DS, they bought the wrong times on satellite for coverage of Pope's
>> # visit. This year, the ending date of DS was postponed to March 1
>> # to help dealing with the shortages of electric power.
>> ;-)
> Good point. I agree.

Timezones can (and do) change at very short notice in different parts of 
the world. Typically computer systems have timezone data cached as part of 
the OS, and only get updates when the OS is itself updated - often long 
after a timezone change has occurred or long after future events were 
booked but are now out of sync for participants in different timezones. To 
address that a number of folks in the calendaring and scheduling community 
have been working om a timezone service protocol - 
<> - our 
initial focus for that has been iCalendar (RFC5545) based VTIMEZONE 
component delivery to calendar and scheduling clients and servers. However, 
we would like to also deliver OS-style timezone data to devices to break 
out of the requirement for those to be updated only when the OS itself 
updates. For unix-based OS's that means being able to deliver "raw" 
zoneinfo" data over that protocol.

Anyway, if you are interested in that work please comment over on the 
ietf-calsify list (cc'd) - we (the authors of that draft) - intend to get 
it moving to last call soon. There are already several implementations that 
have undergone testing at the Calendaring and Scheduling Consortium 
(CalConnect) interop events, so we are happy with it, but would appreciate 
more feedback.

Cyrus Daboo