From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
Cc: | "Watzinger, Alexander" <Alexander(dot)Watzinger(at)oeaw(dot)ac(dot)at>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Support for dates before 4713 BC |
Date: | 2022-09-12 15:00:13 |
Message-ID: | 1622177.1662994813@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> writes:
> On Sun, 21 Aug 2022 at 19:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco Olarte | 2022-09-12 15:30:51 | Re: Resolving host to IP address |
Previous Message | Sebastien Flaesch | 2022-09-12 14:40:16 | Re: Resolving host to IP address |