On Mon, Dec 27, 2010 at 9:23 PM, Leslie S Satenstein <lsatenst...@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 do have 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 negative one --- 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 even though 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 C code. > > I have tested the PG Date C language routines with/without my fix, starting > with the year around -4713 to several centuries into the future. As long as > both versions calculate Julian dates that are later than 1/1/0001, both the > PG and my fixed 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 -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
