Re: A structured format for dates?

Poul-Henning Kamp <phk@phk.freebsd.dk> Thu, 16 June 2022 22:09 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA437C15BE7E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 16 Jun 2022 15:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.66
X-Spam-Level:
X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbdFYJjUexDT for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 16 Jun 2022 15:09:52 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 914EEC1594AF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 16 Jun 2022 15:09:51 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1o1xdF-0002Hi-L4 for ietf-http-wg-dist@listhub.w3.org; Thu, 16 Jun 2022 22:06:29 +0000
Resent-Date: Thu, 16 Jun 2022 22:06:29 +0000
Resent-Message-Id: <E1o1xdF-0002Hi-L4@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <phk@critter.freebsd.dk>) id 1o1xdD-0002GX-Jc for ietf-http-wg@listhub.w3.org; Thu, 16 Jun 2022 22:06:27 +0000
Received: from phk.freebsd.dk ([130.225.244.222]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <phk@critter.freebsd.dk>) id 1o1xd9-0006If-Oa for ietf-http-wg@w3.org; Thu, 16 Jun 2022 22:06:27 +0000
Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 6B5958928B; Thu, 16 Jun 2022 22:06:10 +0000 (UTC)
Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 25GM6FqI063105 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 16 Jun 2022 22:06:15 GMT (envelope-from phk@critter.freebsd.dk)
Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 25GM6EPJ063104; Thu, 16 Jun 2022 22:06:14 GMT (envelope-from phk)
Message-Id: <202206162206.25GM6EPJ063104@critter.freebsd.dk>
To: Austin William Wright <aaa@bzfx.net>
cc: Willy Tarreau <w@1wt.eu>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
In-reply-to: <C1814D1B-D048-4A03-9C26-1BC2E20334A9@bzfx.net>
From: Poul-Henning Kamp <phk@phk.freebsd.dk>
References: <8C9C4A5C-45DB-43C0-9769-2A7510854AB1@mnot.net> <202206160546.25G5k0KR056033@critter.freebsd.dk> <B34DEE15-DE14-4DC2-B6D0-F0CD1823EC30@mnot.net> <20220616062211.GA28947@1wt.eu> <C1814D1B-D048-4A03-9C26-1BC2E20334A9@bzfx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <63102.1655417174.1@critter.freebsd.dk>
Date: Thu, 16 Jun 2022 22:06:14 +0000
Received-SPF: pass client-ip=130.225.244.222; envelope-from=phk@critter.freebsd.dk; helo=phk.freebsd.dk
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: titan.w3.org 1o1xd9-0006If-Oa 0d25cf9e1ff3422b79c6d82b1c88a32b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: A structured format for dates?
Archived-At: <https://www.w3.org/mid/202206162206.25GM6EPJ063104@critter.freebsd.dk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40133
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

--------
Austin William Wright writes:

> 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]

As I mentioned in another email, the leap-second situation has
gotten geophysically rather murky.

I personally think we are unlikely to ever see another leap-second.

Either they will be abolished before the next one becomes necessary
or they will become so unmanageable, that that we either get a
standarized smear algorithm or switch to more predictable time-scales.

> I figure, if fractional seconds are important, then being able to 
> represent a leap-second is probably of some importance.

Fractional seconds are relevant many times every single second.

Leap seconds are at most relevant every 50 million seconds, currently
have not been so for 220 million seconds and are unlikely to be relevant
for at least the next 100 million seconds.

The absolutely simplest, fastest and least error-prone, both in
development, testing and usage, is to ask the kernel for a time_t
and render that as a decimal number.

Making leap-second handling a HTTP requirement in the current
situation would utterly stupid.

Poul-Henning

-- 
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.