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: | Raw Message | Whole Thread | 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 |