| From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
|---|---|
| To: | "cstraka(at)incontactnow(dot)com" <cstraka(at)incontactnow(dot)com> |
| Cc: | "'pgsql-bugs(at)postgresql(dot)org'" <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: to_char miscalculation on April Fool's Day - the start of daylight savings |
| Date: | 2001-04-06 13:54:53 |
| Message-ID: | 3ACDCAAD.74C3210B@alumni.caltech.edu |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> 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).
A known problem which is fixed in the upcoming release. Workaround
follows...
> The quickest demonstration is as follows:
> select to_char(now(), 'YYYY-MM-DD');
Have you tried to use "date 'today'" rather than "now()"? As in
select to_char(date 'today' - 1, 'YYYY-MM-DD');
which uses the DATE type rather than ABSTIME/TIMESTAMP returned from
now(). That should eliminate the problem, since the DATE type does not
try to carry along time zone information. Seems to work for me on 7.0.3.
- Thomas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-04-06 14:22:45 | Re: Re: to_char miscalculation on April Fool's Day - the start of daylight savings |
| Previous Message | Tom Lane | 2001-04-06 05:58:48 | Re: Unexpected query results |