Thomas Lockhart <[EMAIL PROTECTED]> writes:
> In the long run, we should probably implement some exact date/interval
> arithmetic instead of relying on timestamp types in the intermediate
> calculations.
AFAIK type "date" solves his problem just fine, and there's no need to
mess with timestamps a
This was just discussed yesterday on pgsql-novice, see
http://archives.postgresql.org/pgsql-novice/2002-01/msg00177.php
http://archives.postgresql.org/pgsql-novice/2002-01/msg00178.php
regards, tom lane
---(end of broadcast)
...
> Yes, it works!
> But now postgres accepts input and returns output
> in GMT, not local time like before! Is it a feature?
This strategy will not work in general unless you *do* set the time zone
to GMT (if it works at one boundary, say in the fall, then it will fail
at the other boundary in
On Thu, Jan 31, 2002 at 11:44:53AM -0500, Tom Pfau wrote:
> try 'set timezone to ' replacing with your timezone
> before your query.
>
> template1=# set timezone to est;
> SET VARIABLE
> template1=# SELECT date(date '2001-10-28' + interval '1 day');
> date
>
> 2001-10-29
> (1 r
ch the Pravking [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 11:04 AM
To: [EMAIL PROTECTED]
Subject: [BUGS] Dates and daylight saving time
I got the following problem in PostgreSQL 7.1.3.
When I need to get next day relative to another one,
I do the following query:
SELECT date(date
I got the following problem in PostgreSQL 7.1.3.
When I need to get next day relative to another one,
I do the following query:
SELECT date(date ? + interval '1 day').
But on '2001-10-28', I get this:
test=> SELECT date(date '2001-10-28' + interval '1 day');
date
2001-10-28
(1
