Обсуждение: Is there a bug list for the version 9.0.2 PDF file

Excerpts from Leslie S Satenstein's message of dom dic 19 23:55:29 -0300 2010:
> Found a few mistakes, I believe that the problem stems from adobe and it's treatment of single quotes around a word.
> In other places, found differences between my default values (Fedora 14 and also Debian Squeeze), so I would like to
askwhat should be the correct values.  My two systems are 64bit dual core versons. 

Please be more specific about the mistakes you found.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Hi Robert,

If my email is not for the documentation group, please forward.

I am not sure if this has meaning to PG users.

In the 9.0.2 PG documentation that was posted concerning Julian dates, I noted that comments stated that Julian dates
wereused mainly for astronomical calculations. 

I would like to let you know the importance of Julian dates in the ERP manufacturing sector.  In fact, here is how it
isused. 

In the factory, work and material scheduling, as well as material requirements planning usually refers to a
manufacturingcalendar. These calendars often have 1000 working days to a manufacturing year. Using Julian dates in the
softwaremakes it easy to calculate target dates x working days after a given day. Calculations to take the Gregorian
date,convert it to Julian, and then add a duration quantity before converting back, is where the use of the julian date
shines.Calculations for differences between two dates is important and easily done. 

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 even
thoughthe 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
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

Regards

Leslie
(celebrating 40 years in IT).

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

Good morning Robert

I presume that you are the acting project manager, in the sense of vetting changes or commentary.  The pdf guide has
onlyone statement concerning julian dates.  I feel that more is required. 

Julian dates are used as follows.

Working days between two dates is (the difference of the day numbers * 5/7) , with minor adjustment for rounding and
weekendstart-end considerations.  

Julian date conversion is used for this type of calculation.  It would be nice to see more in the manual about Julian
dates,such as tests if a day is a weekend day, or to determine the day of the week for a specific Gregorian calendar
dateand vice-versa. 

Regarding the julian bug(let), I will raise it as a comment on the code buglist.




------------------

Regards
 Leslie
 Mr. Leslie Satenstein

 
mailto:lsatenstein@yahoo.com
mailto leslie.satenstein@itbms.biz / leslies@itbms.biz
www.itbms.biz



--- On Wed, 12/29/10, Robert Haas <robertmhaas@gmail.com> wrote:

> From: Robert Haas <robertmhaas@gmail.com>
> Subject: Re: [DOCS] Some comments about Julian Dates and possible bug. Please provide feedback.
> To: "Leslie S Satenstein" <lsatenstein@yahoo.com>
> Cc: "pgsql-docs" <pgsql-docs@postgresql.org>
> Date: Wednesday, December 29, 2010, 6:58 AM
> 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 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
>

Leslie S Satenstein <lsatenstein@yahoo.com> writes:
>> 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.

This is not a bug, it's just failure to understand the conventions used
internally.  If you did the calculations at the SQL level you would get
the right answers:

regression=# select '0001-01-01'::date - 1;
   ?column?
---------------
 0001-12-31 BC
(1 row)

regression=# select '0001-01-01'::date - '0001-12-31 BC'::date;
 ?column?
----------
        1
(1 row)

Internally we represent 1 BC as "year zero", 2 BC as "year -1", etc,
but this isn't a problem from users' perspective.

            regards, tom lane