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 1oPo2M-0002YJ-EF for pgsql-general@arkaria.postgresql.org; Sun, 21 Aug 2022 16:42:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oPo2J-00040v-BB for pgsql-general@arkaria.postgresql.org; Sun, 21 Aug 2022 16:42:55 +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 1oPP6k-00056o-EU for pgsql-general@lists.postgresql.org; Sat, 20 Aug 2022 14:05:50 +0000 Received: from esa.hc1004-48.eu.iphmx.com ([23.90.110.122]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oPP6g-00064a-8V for pgsql-general@lists.postgresql.org; Sat, 20 Aug 2022 14:05:49 +0000 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from w07ex16db3.arz.oeaw.ac.at (HELO W07EX16DB3.oeaw.ads) ([193.171.197.23]) by esa1.hc1004-48.eu.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Aug 2022 16:05:42 +0200 Received: from w07ex16db2.oeaw.ads (193.171.197.22) by W07EX16DB3.oeaw.ads (193.171.197.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.12; Sat, 20 Aug 2022 16:05:42 +0200 Received: from w07ex16db2.oeaw.ads ([fe80::3cab:8eac:fbf:e8eb]) by W07EX16DB2.oeaw.ads ([fe80::3cab:8eac:fbf:e8eb%3]) with mapi id 15.01.2507.012; Sat, 20 Aug 2022 16:05:42 +0200 From: "Watzinger, Alexander" To: "pgsql-general@lists.postgresql.org" Subject: Support for dates before 4713 BC Thread-Topic: Support for dates before 4713 BC Thread-Index: AQHYtJn21urOZ2Z+b0a+LhRWokxqHw== Date: Sat, 20 Aug 2022 14:05:42 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.170.80.42] Content-Type: multipart/alternative; boundary="_000_ca438ff8331c4e109aa1b75a130948acoeawacat_" MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_ca438ff8331c4e109aa1b75a130948acoeawacat_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I'm working on the open source project OpenAtlas (https://openatlas.eu) whi= ch is used to enter historical and archeological data. Although we really appreciate the wonderful PostgreSQL software, the limita= tion of not being able to use dates before 4713 BC is problematic in regard= to archeological data. The only reason for this limitation I found was that the Julian Calendar wa= sn't created with this in mind. The only suggestion I found was to write an= own implementation just using integers for years. But building a parallel = date system in this case would be way to cumbersome and error prone, we rea= lly like using the database for date operations. So my questions are: Any chance to add support for dates before 4713 BC? We really would appreci= ate that. The 4713 BC limit feels very arbitrary, what is the reason for this exact l= imit? Feedback and pointers are very welcome, Alex -- Alexander Watzinger Austrian Academy of Sciences Austrian Centre for Digital Humanities and Cultural Heritage alexander.watzinger@oeaw.ac.at | www.oeaw.ac.at/acdh --_000_ca438ff8331c4e109aa1b75a130948acoeawacat_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

I'm working on the open source project OpenAtlas (https://openatlas.eu) which is used to= enter historical and archeological data.
Although we really appreciate the wonderful PostgreSQL software, the limita= tion of not being able to use dates before 4713 BC is problematic in regard= to archeological data.
The only reason for this limitation I found was that the Julian Calendar wa= sn't created with this in mind. The only suggestion I found was to write an= own implementation just using integers for years. But building a parallel = date system in this case would be way to cumbersome and error prone, we really like using the d= atabase for date operations.


So my questions are:
Any chance to add support for dates before 4713 BC? We really = would appreciate that.

The 4713 BC limit feels very arbitrary, what is the reason for this exac= t limit?


Feedback and pointers are very welcome,

Alex


--
Alexander Watzinger

Austrian Academy of Sciences
Austrian Centre for Digital Humanities and Cultural Heritage
alexander.watzinger@oeaw.ac.at | www.oeaw.ac.at/acdh

--_000_ca438ff8331c4e109aa1b75a130948acoeawacat_--