From: | Chris Straka <cstraka(at)incontactnow(dot)com> |
---|---|
To: | "'pgsql-bugs(at)postgresql(dot)org'" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | to_char miscalculation on April Fool's Day - the start of daylight savings |
Date: | 2001-04-03 15:22:12 |
Message-ID: | 01C0BC30.57F68640.cstraka@incontactnow.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Likely related to bug #249. I also entered this bug in the bug tool
database
Hello,
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 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;
The bug is specific to April 1. Assuming it's April 3, you get a correct
result of 2000-03-01 if you enter:
select to_char(now() -33, 'YYYY-MM-DD');
I'm running on Red Hat Linux 6.2 - select version() returns the following:
PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66
Please advise if you need more info.
Chris Straka
From | Date | Subject | |
---|---|---|---|
Next Message | Patricia Holben | 2001-04-03 15:22:55 | Re: Table constraint ordering disrupted by pg_dump |
Previous Message | Darcy Buskermolen | 2001-04-03 14:44:11 | Re: PostgreSQL 7.0.2 Date Miscalculation |