Re: A structured format for dates?

Willy Tarreau <> Fri, 17 June 2022 07:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D56C8C15AAEC for <>; Fri, 17 Jun 2022 00:42:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.339
X-Spam-Level: **
X-Spam-Status: No, score=2.339 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Q9TAQncXURv for <>; Fri, 17 Jun 2022 00:42:00 -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 B1D13C15AAE8 for <>; Fri, 17 Jun 2022 00:42:00 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1o26ZK-0001ZG-Sb for; Fri, 17 Jun 2022 07:39:02 +0000
Resent-Date: Fri, 17 Jun 2022 07:39:02 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o26ZI-0001X1-Ls for; Fri, 17 Jun 2022 07:39:00 +0000
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1o26ZH-0004PH-0e for; Fri, 17 Jun 2022 07:39:00 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 25H7cfI8030537; Fri, 17 Jun 2022 09:38:41 +0200
Date: Fri, 17 Jun 2022 09:38:41 +0200
From: Willy Tarreau <>
To: Austin William Wright <>
Cc: Mark Nottingham <>, Poul-Henning Kamp <>, HTTP Working Group <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1o26ZH-0004PH-0e a8cc95e88688f8694e96b0da9c3042f0
Subject: Re: A structured format for dates?
Archived-At: <>
X-Mailing-List: <> archive/latest/40150
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, Jun 16, 2022 at 10:27:58AM -0700, Austin William Wright wrote:
> > The epoch-based representation also has the benefit that you're not required
> > to have to guess a timezone nor to be confused by ":60" resulting from a leap
> > second once every few years.
> Quick, off the top of your head: What happens to the Unix epoch when it
> passes through a leap-second? What about a negative leap second? [1]

In fact all depends whether these dates are intended to be consumed by
humans or machines. Leap seconds were only invented to keep the human
calendar aligned with the stellar one. Computers don't care. And humans
don't care either as long as dates are in fact used to transport a form
of duration. If you need to indicate when a document is supposed to
expire because you added a timeout to the current human date, the expiration
date cannot care less about the leap second than the original date, what
matters is only the duration, which again is just a number of seconds.

There may be situations where human dates are important, e.g. opening an
online vote or the sales for a much sought product where some frustrated
losers could argue that the date was not respected. But I'm not seeing
such dates used for decision making transported in HTTP headers, for the
main reason that the one writing the date cannot know when the consumer
will receive it, thus it's inaccurate by design.

So I tend to think that most of the dates transported in headers, if not
the entirety, are targetted at computers and as such, are essentially
relevant to calculate durations or ages. And there, integers will be
correct by design.

> > Also, applications that want to rely on text-based dates do not all agree
> > on the format. Some would like to see the day-of-week there, others don't
> > want ISO8601 because it's less readable by humans etc. Thus I'd rather go
> > for integer+fraction only.
> But disagreement on a Date format is exactly the problem that is being solved
> here. It is not obvious to me that (a string representation of) a number
> ought to be the winner just because there has been disagreement in the past.

I'm pretty much convinced that as most of the times when there is a long-
lasting disagreement on a design choice, it's because we try to make it
fit different needs. Typically using a date for both durations and human
dates is wrong and cannot satisfy both incompatible needs when accuracy
enters the list of requirements. Even the GPS time that many consider the
most accurate have no care for human time and it's very possible that the
date displayed in your car is off by the sum of all the leap seconds
accumulated since the car was designed and the time offset hard-coded
there! Thus it's possible to have microsecond accurate clocks with integral
numbers of seconds variations. And most of the time even humans don't care.