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 1s81u6-0094qZ-8h for pgsql-bugs@arkaria.postgresql.org; Fri, 17 May 2024 18:02:03 +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 1s81u6-00GBiN-3W for pgsql-bugs@arkaria.postgresql.org; Fri, 17 May 2024 18:02:02 +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 1s81u5-00GBiF-R6 for pgsql-bugs@lists.postgresql.org; Fri, 17 May 2024 18:02:01 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s81tz-000kiY-I8 for pgsql-bugs@lists.postgresql.org; Fri, 17 May 2024 18:02:01 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 44HI1pwL2473626; Fri, 17 May 2024 14:01:51 -0400 From: Tom Lane To: Alvaro Herrera cc: david.perez.ingeniero@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18470: Time literal accepted in Postgres 15 and below, not accepted in Postgres 16 In-reply-to: <2393945.1715956655@sss.pgh.pa.us> References: <202405171346.virffgus6cjg@alvherre.pgsql> <2393945.1715956655@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Fri, 17 May 2024 10:37:35 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2473624.1715968911.1@sss.pgh.pa.us> Date: Fri, 17 May 2024 14:01:51 -0400 Message-ID: <2473625.1715968911@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > I'm not sure whether that wikipedia page should be taken > as authoritative, but if we can convince ourselves that > 'T14:00:00' really is a thing per 8601, then yeah we should > undo that part. Given the lack of ready availability of 8601 itself, perhaps we should assume that everyone's going to believe wikipedia. In any case, what it says is pretty straightforward: As of ISO 8601-1:2019, the basic format is T[hh][mm][ss] and the extended format is T[hh]:[mm]:[ss]. Earlier versions omitted the T (representing time) in both formats. Either the seconds, or the minutes and seconds, may be omitted from the basic or extended time formats for greater brevity but decreased precision; the resulting reduced precision time formats are: T[hh][mm] in basic format or T[hh]:[mm] in extended format, when seconds are omitted. T[hh], when both seconds and minutes are omitted. We previously accepted all of these except T[hh]. I'm inclined to continue to reject that, even if it's nominally standards compliant, because it seems way too likely to be a mistake. Interestingly, the code does still take the "basic" (colon-free) forms: regression=# select time 'T1347'; time ---------- 13:47:00 (1 row) regression=# select time 'T134712'; time ---------- 13:47:12 (1 row) regression=# select time 'T134712.4'; time ------------ 13:47:12.4 (1 row) So at this point, yeah that's a bug we should fix. I'll look into it later if nobody beats me to it. regards, tom lane