to_char miscalculation on April Fool's Day, the start of daylight savings

straka (straka(at)acunet(dot)net) reports a bug with a severity of 1
The lower the number the more severe it is.

Short Description
to_char miscalculation on April Fool's Day, the start of daylight savings

Long Description
Nip this one in the bud because knowledge of it will hinder adoption of PostgreSQL in commercial applications. Probably related to bug 249 - Daylight savings happened in the US on April 1.

It's April 3 and I'm developing an update routine to maintain expired records, some of which expired on April 1. When these records didn't get updated, I investigated and identified the alleged bug (which is potentially devastating financially based on date intensive calculations in financial applications).

The quickest demonstration is as follows:
select to_char(now(), 'YYYY-MM-DD');

Based on the date you see, subtract an integer value from now() so the query result shows 2-Apr. Assuming it's April 3, enter:

select to_char(now() -1, 'YYYY-MM-DD');

It comes back fine with 2001-04-02.

Now decrement by x + 1 to see the bug. Assuming it's April 3, enter:

select to_char(now() - 2, 'YYYY-MM-DD');

It comes back incorrectly with 2001-03-31;

You get a correct result of 2000-03-01 if you enter:
select to_char(now() -33, 'YYYY-MM-DD');

My system is Eastern Daylight Time. I'm running on Red Hat Linux 6.2 - select version() returns the following:
PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled

Sample Code
thedb=# select to_char(now(), 'YYYY-MM-DD');
to_char
------------
2001-04-03
(1 row)

thedb=# select to_char(now() -1, 'YYYY-MM-DD');
to_char
------------
2001-04-02
(1 row)

thedb=# select to_char(now() -2, 'YYYY-MM-DD');
to_char
------------
2001-03-31
(1 row)

thedb=# select to_char(now() -3, 'YYYY-MM-DD');
to_char
------------
2001-03-31
(1 row)

thedb=# select to_char(now() -33, 'YYYY-MM-DD');
to_char
------------
2001-03-01
(1 row)

No file was uploaded with this report