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 1mVwDb-0007aE-Qe for pgsql-bugs@arkaria.postgresql.org; Thu, 30 Sep 2021 13:35:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mVwDa-0007N9-FM for pgsql-bugs@arkaria.postgresql.org; Thu, 30 Sep 2021 13:35:22 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mVwDa-0007N1-8d for pgsql-bugs@lists.postgresql.org; Thu, 30 Sep 2021 13:35:22 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mVwDX-0005EM-6x for pgsql-bugs@lists.postgresql.org; Thu, 30 Sep 2021 13:35:21 +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 18UDZIdU3058341; Thu, 30 Sep 2021 09:35:18 -0400 From: Tom Lane To: =?UTF-8?Q?S=C3=A9bastien_Caunes?= cc: pgsql-bugs@lists.postgresql.org Subject: Re: Bug report function to_date should reject HH24:MI:SS formatting options In-reply-to: References: Comments: In-reply-to =?UTF-8?Q?S=C3=A9bastien_Caunes?= message dated "Thu, 30 Sep 2021 11:03:14 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3058339.1633008918.1@sss.pgh.pa.us> Date: Thu, 30 Sep 2021 09:35:18 -0400 Message-ID: <3058340.1633008918@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk =?UTF-8?Q?S=C3=A9bastien_Caunes?= writes: > TO_DATE function should reject the time part (HH24:MI:SS) in the template > string. We're not going to do that, because it would break interesting use-cases. It's true that you could just omit the time part of the format in the example you gave. But if you want to parse data with the time part appearing first, that doesn't work: regression=# select TO_DATE('08:30:37 2021-09-30', 'HH24:MI:SS YYYY-MM-DD'); to_date ------------ 2021-09-30 (1 row) regression=# select TO_DATE('08:30:37 2021-09-30', 'YYYY-MM-DD'); ERROR: date/time field value out of range: "08:30:37 2021-09-30" > I just saw developers coming from Oracle spending a lot of time on this. A rule of thumb for people coming from Oracle is that uses of to_date and related functions should be nuked from orbit. For just about any common datetime layout, simply casting to the desired type is safer and easier: regression=# select '2021-09-30 08:30:37'::timestamp; timestamp --------------------- 2021-09-30 08:30:37 (1 row) You only need to_date and friends to parse weird formats (like time-of-day first). Our docs do make this point, but perhaps not forcefully enough. regards, tom lane