On Mon, 12 Sept 2022 at 16:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Simon Riggs <simon.riggs@enterprisedb.com> writes:
> > On Sun, 21 Aug 2022 at 19:04, Tom Lane <tgl@sss.pgh.pa.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.
OK, challenge seems clear.
> 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.
The problem is that support for custom datatypes is hard. First, you
have to find a cloud provider that will allow user extensions. Second,
you have to make that work with all the other software that isn't
expecting them.
Not insurmountable, but big enough to make it a barrier for something
fairly small like this.
--
Simon Riggs http://www.EnterpriseDB.com/