Re: A structured format for dates?

Austin William Wright <aaa@bzfx.net> Fri, 17 June 2022 00:24 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 D4C82C157B5B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 16 Jun 2022 17:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.761
X-Spam-Level:
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net
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 rKgzZd28DSzE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 16 Jun 2022 17:24:06 -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 B0374C157B52 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 16 Jun 2022 17:24:06 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1o1zjo-00086z-ND for ietf-http-wg-dist@listhub.w3.org; Fri, 17 Jun 2022 00:21:24 +0000
Resent-Date: Fri, 17 Jun 2022 00:21:24 +0000
Resent-Message-Id: <E1o1zjo-00086z-ND@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 <aaa@bzfx.net>) id 1o1zjm-00085z-KA for ietf-http-wg@listhub.w3.org; Fri, 17 Jun 2022 00:21:22 +0000
Received: from mail-pg1-x531.google.com ([2607:f8b0:4864:20::531]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <aaa@bzfx.net>) id 1o1zjl-0000VQ-4u for ietf-http-wg@w3.org; Fri, 17 Jun 2022 00:21:22 +0000
Received: by mail-pg1-x531.google.com with SMTP id l4so2641560pgh.13 for <ietf-http-wg@w3.org>; Thu, 16 Jun 2022 17:21:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JxxkSvjGnbJowaOxpi0aWSUKYtFVFfeCANSMw0+5uwQ=; b=drjhs5QjbfYtxiDvDqkSTmBlt03U6NT9T8TjecWUIch1QF+7SOGSyIhLF0smkhTLF8 TNfL6oP9z6lIinYM0LL8/O21JOdGrC0pCNHBkoomtzq0ukxPFfp+x2tN71BsOKDMGvve NeMLSVLqZBkIzF/XG/g2K08MuOsiEcvEyLMho=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JxxkSvjGnbJowaOxpi0aWSUKYtFVFfeCANSMw0+5uwQ=; b=tFRwjQvENQ7OA8J+EvjwWSY/D0kRjLWDbZFh02MosulLws2I3Q3c6Sf4NGKgm+fdRV Ykum0GUQ5JAkcLeOOyzPETb7yQkrPRM2SSdDVing3rOg0xgRbixj6Z/XRWbqrXzJ+Pt3 tklS+re8HJCgNhRe29XPCVH0y4qvNK9kBqFcBQVU2A7zuJmyA2VtYwFlS2JEug5vutOH WwuhVg2nvcdpSy02HAeB0AfybjC6yLbNtApG5+WeK9BKRpfXEH3+idMc4+nOd/HQhY1q V2CTRcFgnf5umu69K/Bkt4VIkPQ/PTZF95thFTgBz23CVdT/RN+Mpn/56QFpgyAyPMPW x25w==
X-Gm-Message-State: AJIora+yTikEnh6Nr2dLcIv95f55+Ee9jXLzeL82DZ4wHepTwFbaUekv XTn8hMPyOfEAf9rJL2FiVftQApaJI6yRNg==
X-Google-Smtp-Source: AGRyM1tbI0aLuPxU9/px5kaNOYJQXm5mPoKU350fEOcQhMutPe8haRU5u1N6t/RkxDogOQ1U/ncwaA==
X-Received: by 2002:aa7:8d11:0:b0:51c:4f6d:1562 with SMTP id j17-20020aa78d11000000b0051c4f6d1562mr7367655pfe.14.1655425269584; Thu, 16 Jun 2022 17:21:09 -0700 (PDT)
Received: from smtpclient.apple (71-223-174-56.phnx.qwest.net. [71.223.174.56]) by smtp.gmail.com with ESMTPSA id e12-20020a170902cf4c00b00169071538a0sm1973258plg.267.2022.06.16.17.21.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jun 2022 17:21:09 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Austin William Wright <aaa@bzfx.net>
In-Reply-To: <202206162206.25GM6EPJ063104@critter.freebsd.dk>
Date: Thu, 16 Jun 2022 17:21:07 -0700
Cc: Willy Tarreau <w@1wt.eu>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <24E6D32B-C733-4FA3-B052-898BB86ECFDD@bzfx.net>
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> <202206162206.25GM6EPJ063104@critter.freebsd.dk>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
X-Mailer: Apple Mail (2.3696.100.31)
Received-SPF: pass client-ip=2607:f8b0:4864:20::531; envelope-from=aaa@bzfx.net; helo=mail-pg1-x531.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=aaa@bzfx.net domain=bzfx.net), signature is good
X-W3C-Hub-Spam-Status: No, score=-6.1
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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1o1zjl-0000VQ-4u eca9f25f619e68bd04bf2918d3506d14
X-Original-To: ietf-http-wg@w3.org
Subject: Re: A structured format for dates?
Archived-At: <https://www.w3.org/mid/24E6D32B-C733-4FA3-B052-898BB86ECFDD@bzfx.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40138
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>


> On Jun 16, 2022, at 15:06, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> 
> --------
> 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.

While plausibly true, at the time of writing, this is not a certainty.

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

I don’t believe “works 99.999998% of the time" may be good enough.

If your program crashes and won’t start back up every 50 million seconds because it doesn’t know how to handle a leap second jump, this suddenly becomes quite significant. Which has happened to me on MongoDB.

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

I’m not making a serious argument for the mandatory support of leap seconds. time_t is by definition an integer without sub-second resolution, so the appearance of leap seconds isn’t terribly meaningful.

Rather, if support for fractional seconds is important for any reason at all, then it stands to reason that 1-second discrepancies might cause a few problems. We can either support leap seconds (which for our purposes is nothing more than permitting ":60"), or, take a look at why sub-second resolution would be important to begin with.

Let me propose a different argument for your case: UTC is inherently discontinuous, so if we are not going to have a way to encode these discontinuities, then applications should at least be robust against sudden system clock changes, including into the apparent past. But again, it’s not clear to me that this is a reliable way to solve the problem if certain servers are just going to crash on you.

Cheers,

Austin.

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