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 1oXkvB-0006ah-Cc for pgsql-general@arkaria.postgresql.org; Mon, 12 Sep 2022 15:00:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oXkvA-0001WG-4I for pgsql-general@arkaria.postgresql.org; Mon, 12 Sep 2022 15:00:24 +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 1oXkv9-0001W7-Pp for pgsql-general@lists.postgresql.org; Mon, 12 Sep 2022 15:00:23 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oXkv2-00019h-QZ for pgsql-general@lists.postgresql.org; Mon, 12 Sep 2022 15:00:19 +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 28CF0DGe1622178; Mon, 12 Sep 2022 11:00:13 -0400 From: Tom Lane To: Simon Riggs cc: "Watzinger, Alexander" , "pgsql-general@lists.postgresql.org" Subject: Re: Support for dates before 4713 BC In-reply-to: References: <4161384.1661105052@sss.pgh.pa.us> Comments: In-reply-to Simon Riggs message dated "Mon, 12 Sep 2022 15:40:09 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1622176.1662994813.1@sss.pgh.pa.us> Date: Mon, 12 Sep 2022 11:00:13 -0400 Message-ID: <1622177.1662994813@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Simon Riggs writes: > On Sun, 21 Aug 2022 at 19:04, Tom Lane wrote: >> There are existing equations for calculating Gregorian month/day/year from >> Julian day count [1]. They work back to Julian day zero, at least if >> you grant that proleptic Gregorian dates are sensible that far back. >> Nobody around here has looked into whether they'd work for negative Julian >> day numbers (I suspect not though, at least not without work that seems >> rather pointless). > Sounds reasonable. So the 4713BC limit applies because of the > resolution of 1 day. No, it applies because we aren't sure that the math would operate correctly with negative Julian day numbers --- for instance, division roundoffs might happen in the wrong direction. If somebody wanted to go through and check/fix all that, we could probably relax the restriction. I'm still failing to see the point though. As already discussed upthread, the SQL datetime types aren't very suitable for dealing with approximate dates, multiple calendars, etc. regards, tom lane