[rob@camel rms_db]$ cal 9 1752
September 1752
Su Mo Tu We Th Fr Sa
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
I guess adding 1 day to 1752-09-02 should give us 1752-09-14, but your
right, it gives us 1752-09-03.
Forwarding this to -bugs
Robert Treat
On Sun, 2003-02-23 at 11:22, Aspire Something wrote:
> Hi all ,
> Please Permit me to recive ur valuable knowledge and experience :-)
>
> In the Postgresql Documentation (read it in /7.3.2/units-history.html)
> it has been given that Postgresql follows the Julian calander (Which
> indead is being used by my system by default )
>
> So does it not mean when I add to a date (integer) it must return the
> date as per the calendar :
>
> i.e
>
> The following sql statements
> retuns date 1752-09-03
> insted of 1752-09-14
> you may do :
> $cal 9 1752
> on unix promt to verify (Windows user sorry ur calendar may not show
> dates <1970 !!! atleat mine does not )
> <code>
> select date('1752-09-02') + 1 as some_date ;
> some_date
> ------------
> 1752-09-03
> (1 row)
> select date('1752-09-02') + interval'1 day' as some_day;
> some_day
> ---------------------
> 1752-09-03 00:00:00
> (1 row)
> </code>
> Now every thing above may sound stupid but if we in near future come
> accross the same situation how will the data base respond when my
> database relies 90% on the timestamp value
> their will be total mismatch of calendar(Which people follow) and
> database returning dates.
>
> Regards ,
> Aspire
>
> My Sys Config is
> ==================
> Red Hate 7.2 Kernel 2.4.7-10 on an i686
> Postgresql 7.3.2
> GCC 3.0.2 20010905
> =================
>
