IETF Logo Mail Archive

Re: [Sedate] A syntax proposal: floating and future times

Neil Jenkins <neilj@fastmailteam.com> Mon, 08 November 2021 11:44 UTC

Return-Path: <neilj@fastmailteam.com>
X-Original-To: sedate@ietfa.amsl.com
Delivered-To: sedate@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467503A0CC8 for <sedate@ietfa.amsl.com>; Mon, 8 Nov 2021 03:44:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=JEDGzpiF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ozsnt0wM
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 T-B4QkjkhO4T for <sedate@ietfa.amsl.com>; Mon, 8 Nov 2021 03:44:27 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3183A0CA6 for <sedate@ietf.org>; Mon, 8 Nov 2021 03:44:27 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 96A145C018C for <sedate@ietf.org>; Mon, 8 Nov 2021 06:44:26 -0500 (EST)
Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Mon, 08 Nov 2021 06:44:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=bTI1Oq8 mueqHWGFurr74ZgUMPb+Jz0ESTVttqC4kplc=; b=JEDGzpiFJ4xL0bgsbnfW/Q8 oGmSj1HQWVW0lK6PbmIZciKcdwvXSpyQajKWKOwiAG/6el1jGG7/YQ72MZAOUIgX MMnx8Yu+DxpbYOOjvP/t7k3xlLDYeG9HA4BsnLZjZk5hyEFx2JWKygMGbSrkHMwi zrZv3D4LpYw1mHxQgMlWnn9r6l6pobxSr117OXkKj2ypSabEp0jq996yr5041SJz o//jrv10/8CTx0KWXZWFrakd53iD4iDa0FEDDo1E//tHik7AFMkQj1r+9RN8FVBF Urqg+IbmlW4g4bDarhb2lDF2j8xvaRhylqixjPF8nDubAm3mxVFzT7Ls+VkxD2g= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=bTI1Oq 8mueqHWGFurr74ZgUMPb+Jz0ESTVttqC4kplc=; b=Ozsnt0wMel3z4pNBch74bf dTCuS7GM+0pMDGVBpOjS71A6rIB3Se+BAq6ujG3GOo86G5ikIG0282b1PBKJ8oCw uvYNJoyA8gIl8wZ7X827b0qyIXU1oirHXhU5PBDrzdKOKs8HESuICNvQBWjwRP+y fiut7tx3My1SeU9RRirX6u63CddbZKvHFM/7ibRp58GYbdxEpsPtPyCsB7LgRxYr Zv3fpHIRaNHKvvfxB9H2PUF36oDwrR9YfM5bKOUr7IiTbtxnEY/V2OBbhYdJrg7a Q/NGqThc38RvHFD4rM96X/pyyGOHIMqboHSDHhBYBA6zOqQKoTiGPoBk2qU/UH7A ==
X-ME-Sender: <xms:mg2JYSWoWLPkX-BlI2QlybKmEEj5ykU5jdeoe2qOnDeAgiilNW61ZA> <xme:mg2JYenx4mOg5zEedQPFWzCdVIQxm4oyVxktw58dYGF3vl5zjpp3bSy3kBRwNLyt6 b8I0lAGso1Wtw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddvgdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeehuefhudejtdeive ekvdfhfffgleeflefhfeekhefhkeelkefhfeeufeevffejieenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh
X-ME-Proxy: <xmx:mg2JYWauJHUxj9rhyiMb0c9ZRrP2T0sBDmiuaaahGaGFigXKPLvA8g> <xmx:mg2JYZVROVRfT-8ALhgoC1MYbBFhco8DwFFCNLUX7_9WOkeXvtQXhg> <xmx:mg2JYcleUwNA9ATb-Zf0WKRrYwnAOmtEVhGYHP2Xw15gZHY4Zawe9g> <xmx:mg2JYYwShgPXZLB_PjJaSVEaGZpoIT61mLscwmEVEWiTBKHTZTgabw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 763E5AC0DD1; Mon, 8 Nov 2021 06:44:26 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1420-gdf09e8761c-fm-20211101.001-gdf09e876
Mime-Version: 1.0
Message-Id: <66661871-ff4c-4e0f-93a1-9bbd25a18e39@dogfood.fastmail.com>
In-Reply-To: <CACy7CfjCCTVM9Dbu6EDJ_2kZbNkAge0kRYosmJ0Tv_dB7Hq7-w@mail.gmail.com>
References: <dd7c1028-09bc-4839-b6d4-68e14e99b349@dogfood.fastmail.com> <c0dbaa85-5e5e-409d-a613-9302e9103283@dogfood.fastmail.com> <088a5135-1a39-4135-b8d7-e61113e3c143@beta.fastmail.com> <8964ee5c-463e-44cd-a2b4-e1e1a419337b@dogfood.fastmail.com> <CACy7CfgD+P9GZHy2HG=dSYubJyutX_7YnnW-gj=4FXbV1n4Anw@mail.gmail.com> <67cbf820-a116-4c6b-aa2d-539174668021@dogfood.fastmail.com> <CACy7CfjCCTVM9Dbu6EDJ_2kZbNkAge0kRYosmJ0Tv_dB7Hq7-w@mail.gmail.com>
Date: Mon, 08 Nov 2021 22:44:26 +1100
From: Neil Jenkins <neilj@fastmailteam.com>
To: sedate@ietf.org
Content-Type: multipart/alternative; boundary="9d374bb01ef94832a9d2efb51d77676a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sedate/OaY24q6ulPwlZF_u-xCQ7VeCS4I>
Subject: Re: [Sedate] A syntax proposal: floating and future times
X-BeenThere: sedate@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Serialising Extended Data About Times and Events <sedate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sedate>, <mailto:sedate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sedate/>
List-Post: <mailto:sedate@ietf.org>
List-Help: <mailto:sedate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sedate>, <mailto:sedate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2021 11:44:39 -0000

On Mon, 8 Nov 2021, at 21:38, Justin Grant wrote:
> What I'm hearing from Bron (which I agree with) is that there should be a standardized syntax for floating times like "10:00AM on 20 January 2025 in Melbourne".  This is how calendaring apps will store future meetings.

Just to be clear on terminology, in the calendaring world "floating time" specifically means "wall clock time", i.e. no time zone. The above example is just a date + time zone (but the exact UTC value could change if it's a future date and the time zone definition changes).

> I'd suggest that one way to achieve both camps' goals might be to split the RFC text into two buckets (I'm assuming sections in the same document):

That works for me.

—Neil

v2.23.0 | Report a Bug | By Email