To: Hosen, John
Cc: 'Thomas Lockhart'; '[EMAIL PROTECTED]'
Subject: Re: [HACKERS] 'epoch'::timestamp and Daylight Savings
"Hosen, John" <[EMAIL PROTECTED]> writes:
> e_app_print_date | timestamp with time zone | default
> "timestamp"(
Create table arnold (
a int8,
b timestamp default 'epoch'::timestamp,
c timestamp default "timestamp"('epoch'::text)
);
I think that the best way forward for us (short of re-writing the backend to
use NULL) will be to just alter the default value to the one in column b in
the test table above.
We have just upgraded from 7.1.3 to 7.2.3 over the weekend, and have just
noticed something weird with regards 'epoch'::timestamp.
In 7.1.3, 'epoch'::timestamp always returned the value 1970-01-01
00:00:00+00,...
I would expect 'epoch'::timestamp to always act as though the value were
the same a
"Hosen, John" <[EMAIL PROTECTED]> writes:
> e_app_print_date | timestamp with time zone | default
> "timestamp"('epoch'::text)
Yeah, there's your problem. You are casting 'epoch' to type timestamp
without time zone, and thence to timestamp with time zone. The first
step gives "midnight" and t
Thomas,
Thanks for replying so quickly.
Upon some further investigation, the conversion of the time to BST is OK on
data inserted before the upgrade (the display was just a red herring), the
problem is just on new data inserted into the table with a default value for
the timestamp fields.
The ou
Patrick Welche writes:
> http://www.postgresql.org/devel-corner/docs/user/functions-datetime.html
>
> patrimoine=# SELECT EXTRACT(EPOCH FROM TIMESTAMP '2001-02-16 20:38:40');
> ERROR: parser: parse error at or near "epoch"
> patrimoine=# select version();
> ve
