On Mon, Dec 27, 2010 at 9:23 PM, Leslie S Satenstein
<lsatenstein@yahoo.com> wrote:
> I found the Julian date code that is programmed in Postgres, to be accurate and fast except for one situation. But, I
dohave one or two questions. 1) Which calendar is being used?
>
> In the Gregorian Calendar, January 1, 0001 is lowest positive date.
> The day before 1/1/0001, according to the Gregorian calendar is December 31,-0001 in which the year has a value of
negativeone --- there is no zero year in the Gregorian Calendar. (zero year is an error)
>
> I tested and found the algorithm in Postgres to have the day before January 1,0001 calculating as December 31,0000
eventhough the world calculates the day before January 1,0001 as December 31,-0001.
>
> 2) Is the algorithm in Postgres correct? I think not, as the calculations for the difference in days between January
1,0001 and December 31,-0001 is not 367 days, but just the value 1.
>
> To convert the code to work with the Gregorian calendar takes two fixes to two sub-routines. Each fix is two lines of
Ccode.
>
> I have tested the PG Date C language routines with/without my fix, starting with the year around -4713 to several
centuriesinto the future. As long as both versions calculate Julian dates that are later than 1/1/0001, both the PG and
myfixed versions respecting Gregorian algorithms produce identical results.
>
> 3) Does PG want to fully follow the Gregorian Calendar rule? If so,
> 4) do they want my one patch with two fixes6
This seems like it'd be more appropriate for pgsql-bugs or
pgsql-hackers rather than here. I can't really figure out exactly
what change you're proposing, so I'm not entirely sure whether it's
right or wrong. Perhaps you could post your patch, and some examples.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company