Re: A structured format for dates?

Mark Nottingham <> Fri, 17 June 2022 05:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26A3FC14CF10 for <>; Thu, 16 Jun 2022 22:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.761
X-Spam-Status: No, score=-2.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=k7XzbmHq; dkim=pass (2048-bit key) header.b=MBsPsqK4
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cpuEt3vEOfth for <>; Thu, 16 Jun 2022 22:47:44 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 3D1CCC14CF07 for <>; Thu, 16 Jun 2022 22:47:44 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1o24pU-00028Q-Lw for; Fri, 17 Jun 2022 05:47:36 +0000
Resent-Date: Fri, 17 Jun 2022 05:47:36 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o24pS-000276-Nt for; Fri, 17 Jun 2022 05:47:34 +0000
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o24pR-00016K-12 for; Fri, 17 Jun 2022 05:47:34 +0000
Received: from compute2.internal (compute2.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 2561532001C6 for <>; Fri, 17 Jun 2022 01:47:20 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute2.internal (MEProxy); Fri, 17 Jun 2022 01:47:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1655444839; x= 1655531239; bh=U1cCgZnS2ehmGESxt0qQTVqmGHIz3quFK+DLJq4La40=; b=k 7XzbmHqwUc6M8RzU7jA2necn0VOVBL7J8yb0T+0v5TREg5lWbrmrnwQfrALJN2xg e6AjJKGp5SIN9XhCNBpmWi4HDc7rq+LypG3VJOQY9K3BPsk2EuqxzQz1xWQC/mHG N0sdwEo4e8q8hkZHMZSCGBKbbl8iry8Qogb2/1MeaALIjk8LJB4p7Znabi2OdP92 J9Z5IfOBdSPnWwfoyZn+QukHo2lYh01EgYOmiDcRrSgjHFHMKtJT9Kg3wDPHKnhO UmrCmsrtyME0Rf8QrMQesgSs8STehT6UajA4vOOspfWvgYbjHF/7O1Quid433/6Y NUHjD/Ra+Mvr1QFBgm5Qw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1655444839; x=1655531239; bh=U 1cCgZnS2ehmGESxt0qQTVqmGHIz3quFK+DLJq4La40=; b=MBsPsqK4n5NnYpKds gNDnX/0pX5N66S+hTQYx9GQZbQBGMCaM7za4V0L74CNF/THxP0RQhLbL3J4TVWcg NgYtaiDWNffFNxI+jHmyra73u5uF7T4gZbnPQSk19wDHgcX/WB99fAUPDs9I8ndP gmUFjGaP/26gK0uDz0L719VayzmZwcFRTeRPIND7PhMmLawAFkiJQpANvHR9ZMsR qy8vFoXSYvUmUpRlKXgVhJ+CLloIFFsMjL2T0HnbbNnoqTq5o4f2tNNQOv9P9FpR EZi20FVNAgFbloqxNpwe+K5Oi/ciUsbP45ABWx53ePnGj2k7w6/ZogdNdz8fQfbe wEeAw==
X-ME-Sender: <xms:ZxWsYkayn5q8az2YvGFToHAGcDoA363SBXlwE13HvysqpXDvE8qXZA> <xme:ZxWsYvbnp6RW5HAc9xtusxOdyPaq8r-6oPSOb8cTFOKZj2wh0SY68TLAsh2cqdZM6 Og5feZrbkADzHybcQ>
X-ME-Received: <xmr:ZxWsYu8fDRiCUKrEOtriN6yvhmRsz8sGC5DzpwJSqB-smVUtWu1Dx-KAyYuk8seQv7JlC69BvzjEop3wAeXGp5IOMezYV1Ak_TrENjQZFKsjKE7aVkz9Wq7J>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddvgedgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfuffhfvfgjkffosehtqh hmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepgfehjeehkeekgfeiuddtkeffvefhgf fghedtledvhfefueektdekuddvkeffheeunecuffhomhgrihhnpehmnhhothdrnhgvthen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhoth esmhhnohhtrdhnvght
X-ME-Proxy: <xmx:ZxWsYuq-fv8uWgDkLLetMjn73DR2tRLR9oFDHGFE30RTwcFUztFxfg> <xmx:ZxWsYvpJedAOhWXjk8C0PyzZq4elVPEiOZVGSE9v2rQ2l5qm4U5Vxg> <xmx:ZxWsYsS3eTt2NqKyu_0K5hesRLEQ9ECCt0hUsnbh1_YjIvqvd1ClNQ> <xmx:ZxWsYuSrXnflohIZZB5NKKN4DWJ1zf3XTzwo5pXB08IBFdQOdE9daA>
Feedback-ID: ie6694242:Fastmail
Received: by (Postfix) with ESMTPA for <>; Fri, 17 Jun 2022 01:47:18 -0400 (EDT)
From: Mark Nottingham <>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Date: Fri, 17 Jun 2022 15:47:16 +1000
References: <> <> <> <> <> <> <> <>
To: HTTP Working Group <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3696.100.31)
Received-SPF: pass client-ip=;;
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1o24pR-00016K-12 06b4f6f32eff698da467b42dcce77ca9
Subject: Re: A structured format for dates?
Archived-At: <>
X-Mailing-List: <> archive/latest/40145
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I agree that we'd be *very* much out on a limb if we don't adopt an already defined model for time.

So, that returns us to the original question --  whether we need a distinct data type in SF for dates. As far as I can tell, the distinguishing issue is whether knowledge of the specific header is needed to create a human-friendly representation of it.

If dates are Integers (or Decimals), someone examining that field will need to know that the Integer/Decimal represents a date to be able to present it. Tools could have a list of such fields, but they'd need to be updated from time to time (or have a way of manually flagging a field as a date).

If dates are their own distinct data type in SF, the underlying data model would still be an integer or decimal, but it would self-identify as a date, so that tooling could identify it as such automatically.

When we originally did SF, personally I was unconvinced that the benefit of automated recognition for the purpose of human-friendly presentation was compelling enough to justify a separate data type; the set of date-oriented fields is relatively small, and in most cases the application in question *does* have knowledge of the field's semantics when handling it. The only exception might be generic debugging tools, but again, not terribly compelling.

I'm happy to change my mind if folks feel differently, or (especially) if there's another compelling reason to have a date-specific type. However, I'm seeing pushback from the HTTPAPI folks about having *anything* that doesn't look exactly like the Sunset header field (which IMO is shortsighted), and so far it seems like most folks here are happy with the direction that we currently have in Retrofit -- using Integer (or Decimal). 

I'm going to make one final proposal in HTTPAPI to see if that changes any minds, but if not I think we should close this issue.


> On 17 Jun 2022, at 3:31 pm, Poul-Henning Kamp <> wrote:
> --------
> Austin William Wright writes:
>> I don't believe 'works 99.999998% of the time" may be 
>> good enough.
> Well, that's what everything based on POSIX offers today.
> Trying to compensate for that deficiency in the HTTP layer is
> counter-indicated:  We should take, and trust, the time from the
> platform we run on, and handle leap seconds however that platform
> does.  If the platform jumps over leap-seconds, we should
> follow it, if it smears over them, we should slide along.
>> Rather, if support for fractional seconds is important for any reason at 
>> all, [...]
> Last we talked about it, the CDN people really wanted it for things like
> Cache-Control etc.
>> Let me propose a different argument for your case: UTC is inherently 
>> discontinuous, [...]
> and all HTTP relevant practical realizations of UTC have variable
> frequency.
> But again: Inventing a new time-keeping paradigm for HTTP is a non-starter.
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.

Mark Nottingham