Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pYbM2-0000em-2u for pgsql-hackers@arkaria.postgresql.org; Sat, 04 Mar 2023 23:31:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pYbM0-0005iJ-M5 for pgsql-hackers@arkaria.postgresql.org; Sat, 04 Mar 2023 23:31:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pYbM0-0005i9-8p for pgsql-hackers@lists.postgresql.org; Sat, 04 Mar 2023 23:31:52 +0000 Received: from mail-oo1-xc2e.google.com ([2607:f8b0:4864:20::c2e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pYbLx-0005UN-BF for pgsql-hackers@lists.postgresql.org; Sat, 04 Mar 2023 23:31:51 +0000 Received: by mail-oo1-xc2e.google.com with SMTP id e12-20020a4ae0cc000000b00525034ca5e9so1031428oot.0 for ; Sat, 04 Mar 2023 15:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677972707; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LwApDWDHIftChBxJ3OEkOtq3FPNbVx8qkaZWZYx1MgQ=; b=GQv8RHM5v/G95YZ8imkaqBc+jXt7huKvfd2tFfnu7ZtYq2rLQHWpAxgYoq7pu9V63g wm/Hd7V5m+F/UqdDtv5mEDXLf6OS8jFduz/X1owRD4SOU13Id4xeuJn3p44OPBYmH6Du 9k2oNFyOVS570H7F30Z1rsn/5XqYR3GTtTLFTnzpIY2hRMdrPXKTaQKdn5ZskD2ZHZtF fhUHQX37CxOpQPCLha90+QbuH1CmE6yn8Opm8IpO6fdrzeoQ2ITxQJ8PQXkAPNQFqPxl BGZ9nlnSpKLkFNTzaFfD83J349XXKwZx2HGuJpko+8J/7mfU27IHsbY73ZnRQQT11PBO Jthw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677972707; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LwApDWDHIftChBxJ3OEkOtq3FPNbVx8qkaZWZYx1MgQ=; b=wUFj733MQNp26isdYHx1IbNx9d7nkJAps2lqHgv/jBFMZhMswYiQA7u9twFeZxg+sZ cOSFc4AcHeFERqJOwv+IFb8xdIi6EIBzGenmCEz4dc6nVcE2MEuppAnoQXFZBHJfbVRy urXpMgrIF6VRYGQyyz5zswcgj8ohmCmhqSITNBimDuiXmQ9SESL6Kkul7fvQ57nAu0jP DHx3AYZ2MD9uerDThmodpK0qpRnt8xg5PtccW3xHzQpPkjQ8AdfI8Izdtq7TnWmMef8e zCyOov+rf0DWC8cKVUYOpGqD7hFUuQ+HAwECAsn/wjijASPFKpOrfo/AjUaODdVcCeS+ vrZw== X-Gm-Message-State: AO0yUKVKVODzGi0ZGChsvyvIhtPJnuo/UHnwq6RqSg3++iJbLVtkNFTS pKwBgYmWNrR1BhKCd42j47Puvd+8OsU4MQURYx5cmM3+sg== X-Google-Smtp-Source: AK7set+eNFmho9iAAqMe+p5U+3H5FbzGRoj6gx+eLuP3Ij2on2OYH3XT+NYOfrFLRYsCGLC02LV1r0cSMOjnPT0c3o4= X-Received: by 2002:a4a:da01:0:b0:524:f77c:5443 with SMTP id e1-20020a4ada01000000b00524f77c5443mr2046147oou.1.1677972707061; Sat, 04 Mar 2023 15:31:47 -0800 (PST) MIME-Version: 1.0 References: <2996004.1677963933@sss.pgh.pa.us> In-Reply-To: <2996004.1677963933@sss.pgh.pa.us> From: Joseph Koshakow Date: Sat, 4 Mar 2023 18:31:36 -0500 Message-ID: Subject: Re: Date-Time dangling unit fix To: Tom Lane Cc: PostgreSQL Hackers , lockhart@fourpalms.org Content-Type: multipart/alternative; boundary="00000000000025b4d105f61b7748" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000025b4d105f61b7748 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 4, 2023 at 4:05=E2=80=AFPM Tom Lane wrote: > > I started to look at this, and soon noticed that while we have test cases > matching this sort of date input, there is no documentation for it. The > code claims it's an "ISO" (presumably ISO 8601) format, and maybe it i= s > because it looks a lot like the ISO 8601 format for intervals (durations). > But I don't have a copy of ISO 8601, and some googling fails to find any > indication that anybody else believes this is a valid datetime format. > Wikipedia for example documents a lot of variants of ISO 8601 [1], > but nothing that looks like this. > > I wonder if we should just rip this code out instead of fixing it. > I suspect its real-world usage is not different from zero. We'd > have to keep the "Jnnn" Julian-date case, though, so maybe there's > little to be saved. > > If we do keep it, there's documentation work to be done. But the > first bit of doco I'd want to see is a pointer to a standard. I also don't have a copy of ISO 8601 and wasn't able to find anything about this variant on Google. I did find this comment in datetime.c /* * Was this an "ISO date" with embedded field labels? An * example is "y2001m02d04" - thomas 2001-02-04 */ which comes from this commit [1], which was authored by Thomas Lockhart (presumably the same thomas from the comment). I've CC'ed Thomas in case the email still exists and they happen to remember. The commit message mentions ISO, but not the variant mentioned in the comment. The mailing list thread can be found here [2], but it doesn't provide much more information. I also found the following thread [3], which happens to have you in it in case you remember it, which seemed to be the motivation for commit [1]. It only contains the following line about ISO: > o support for "ISO variants" on input, including embedded "T" preceeding the time fields All that seems to imply the "y2001m02d04" ISO variant was never really discussed in much detail and it's probably fine to remove it. Though, it has been around for 22 years which makes it a bit scary to remove. - Joe Koshakow [1] https://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dcommit;h=3D6f5811= 5dddfa8ca63004c4784f57ef660422861d [2] https://www.postgresql.org/message-id/flat/3BB433D5.3CB4164E%40fourpalms.or= g [3] https://www.postgresql.org/message-id/flat/3B970FF8.B9990807%40fourpalms.or= g#c57d83c80d295bfa19887c92122369c3 --00000000000025b4d105f61b7748 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Mar 4, 2023 at 4:05=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
= > =C2=A0 =C2=A0I started to look at this, and soon noticed that while we= have test cases
> =C2=A0 =C2=A0matching this sort of date input, the= re is no documentation for it.=C2=A0 The
> =C2=A0 =C2=A0code claims i= t's an "ISO" (presumably ISO 8601) format, and maybe it is> =C2=A0 =C2=A0because it looks a lot like the ISO 8601 format for inte= rvals (durations).
> =C2=A0 =C2=A0But I don't have a copy of ISO = 8601, and some googling fails to find any
> =C2=A0 =C2=A0indication t= hat anybody else believes this is a valid datetime format.
> =C2=A0 = =C2=A0Wikipedia for example documents a lot of variants of ISO 8601 [1],> =C2=A0 =C2=A0but nothing that looks like this.
>
> =C2=A0= =C2=A0I wonder if we should just rip this code out instead of fixing it.> =C2=A0 =C2=A0I suspect its real-world usage is not different from ze= ro.=C2=A0 We'd
> =C2=A0 =C2=A0have to keep the "Jnnn" J= ulian-date case, though, so maybe there's
> =C2=A0 =C2=A0little t= o be saved.
>
> =C2=A0 =C2=A0If we do keep it, there's docu= mentation work to be done.=C2=A0 But the
> =C2=A0 =C2=A0first bit of = doco I'd want to see is a pointer to a standard.

I also don'= t have a copy of ISO 8601 and wasn't able to find anything
about thi= s variant on Google. I did find this comment in datetime.c

/*
= * Was this an "ISO date" with embedded field labels? An
* ex= ample is "y2001m02d04" - thomas 2001-02-04
*/

which c= omes from this commit [1], which was authored by Thomas Lockhart
(presum= ably the same thomas from the comment). I've CC'ed Thomas in
cas= e the email still exists and they happen to remember. The commit
message= mentions ISO, but not the variant mentioned in the comment.
The mailing= list thread can be found here [2], but it doesn't provide
much more= information. I also found the following thread [3], which
happens to ha= ve you in it in case you remember it, which seemed to be
the motivation = for commit [1]. It only contains the following line
about ISO:

&g= t; o support for "ISO variants" on input, including embedded &quo= t;T" preceeding
the time fields

All that seems to imply the = "y2001m02d04" ISO variant was never really
discussed in much d= etail and it's probably fine to remove it. Though,
it has been aroun= d for 22 years which makes it a bit scary to remove.

- Joe Koshakow<= br>
[1] https://git.postg= resql.org/gitweb/?p=3Dpostgresql.git;a=3Dcommit;h=3D6f58115dddfa8ca63004c47= 84f57ef660422861d
[2] https://www.postgresql.org/messa= ge-id/flat/3BB433D5.3CB4164E%40fourpalms.org
[3] https://www.postgresql.org/message-id/flat/3B97= 0FF8.B9990807%40fourpalms.org#c57d83c80d295bfa19887c92122369c3
--00000000000025b4d105f61b7748--