Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sL5C0-00DNnh-16 for pgsql-hackers@arkaria.postgresql.org; Sat, 22 Jun 2024 18:10:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sL5By-00DHqs-8r for pgsql-hackers@arkaria.postgresql.org; Sat, 22 Jun 2024 18:10:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sL5Bx-00DHqf-OS for pgsql-hackers@lists.postgresql.org; Sat, 22 Jun 2024 18:10:26 +0000 Received: from pb-smtp20.pobox.com ([173.228.157.52]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sL5Bv-0031HG-0n for pgsql-hackers@lists.postgresql.org; Sat, 22 Jun 2024 18:10:25 +0000 Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 7CCE13D8AA; Sat, 22 Jun 2024 14:10:19 -0400 (EDT) (envelope-from david@justatheory.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=sasl; bh= +qwPpSgpx29z+42wilhaHpyMT9OERQ5gnhOorl69eIg=; b=b0h5eVYxZtxTw+Zh G4+swQX1JZyBIz9N2Vb4iaji7oKILJtzPqg7uqDTGfyyuPt7AsQFUzq+u3mFcSEL p21akRylgUaynSjtVs01+F+DLWTDox+vtYgRKlnfajrXvFCTx3plt5JJb/rqi4cz dGuvcC18FKC1CEifd3kPZ7n9zes= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 74D133D8A9; Sat, 22 Jun 2024 14:10:19 -0400 (EDT) (envelope-from david@justatheory.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=justatheory.com; h=content-type:mime-version:subject:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=2016-12.pbsmtp; bh=+qwPpSgpx29z+42wilhaHpyMT9OERQ5gnhOorl69eIg=; b=h95vlRORzzj7eAGpzk39nBRxirsSe+duH72bYJDOD53evrtV2w+2iYg0BFxOAPVFzVBAhE8SYZTVa3eDKbA6A2SJlxtrrSa7taZ55Uyb7OqAg/56p6DIjuxlMXDFcX1C4JhzW37hOpXnI9UADW8eSwmi4KGoCwKxQ3+c9bU/ZRo= Received: from smtpclient.apple (unknown [158.222.197.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 04ACF3D8A7; Sat, 22 Jun 2024 14:10:12 -0400 (EDT) (envelope-from david@justatheory.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: Inconsistent Parsing of Offsets with Seconds From: "David E. Wheeler" In-Reply-To: <788148.1719076559@sss.pgh.pa.us> Date: Sat, 22 Jun 2024 14:10:00 -0400 Cc: PostgreSQL Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <4E09AE2B-918D-40BA-B1DE-534BCC9A873F@justatheory.com> References: <788148.1719076559@sss.pgh.pa.us> To: Tom Lane X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Pobox-Relay-ID: AB9689B4-30C2-11EF-ABFF-C38742FD603B-76319746!pb-smtp20.pobox.com List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Jun 22, 2024, at 13:15, Tom Lane wrote: > It's hard to get excited about this. I freely admit I=E2=80=99m getting into the weeds here. :-) >> The corresponding jsonpath methods don=E2=80=99t like offsets with = seconds *at all*: >=20 > Perhaps that should be fixed, but it's pretty low-priority IMO. > I doubt there is any standard saying that JSON timestamps need > to be able to include that. >=20 >> I see from the source[1] that offsets between plus or minus 15:59:59 >> are allowed; should the `OF` and `TZ formats be able to parse them? >=20 > I'd vote no. to_date/to_char already have enough trouble with format > strings being squishier than one might expect. I believe the former issue is caused by the latter: The jsonpath = implementation uses the formatting strings to parse the timestamps[1], = and since there is no formatting to support offsets with seconds, it = doesn=E2=80=99t work at all in JSON timestamp parsing. [1]: = https://github.com/postgres/postgres/blob/70a845c/src/backend/utils/adt/js= onpath_exec.c#L2420-L2442 So if we were to fix the parsing of offsets in jsonpath, we=E2=80=99d = either have to change the parsing code there or augment the = to_timestamp() formats and use them. Totally agree not a priority; happy to just pretend offsets with seconds = don=E2=80=99t exist in any practical sense. Best, David