From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Josh Berkus" <josh(at)agliodbs(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org, Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
Subject: | Re: Calculation Error on Epoch? |
Date: | 2002-08-28 04:14:38 |
Message-ID: | 17502.1030508078@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
"Josh Berkus" <josh(at)agliodbs(dot)com> writes:
> I'm having a problem with:
> SELECT date_part('epoch','2002-08-28'::TIMESTAMP)
> Which is consistently returning an epoch timestamp that evaluates to
> 8.27.2002. Is this a known issue? A cross-platform problem?
In 7.2 I get:
regression=# SELECT date_part('epoch','2002-08-28'::TIMESTAMP);
date_part
------------
1030507200
(1 row)
which seems to be correct given my timezone:
$ prdate 1030507200
time 1030507200 = Wed Aug 28 2002, 00:00:00 EDT
(prdate is a homegrown utility that just does strftime(localtime(...)))
It does seem to be broken in CVS tip, as I've complained to Thomas
at least once:
regression=# SELECT date_part('epoch','2002-08-28'::TIMESTAMP);
date_part
-----------
1030.4928 -- wrong
(1 row)
regression=# SELECT date_part('epoch','2002-08-28'::TIMESTAMPTZ);
date_part
------------
1030507200 -- right
(1 row)
What context are you testing in, and what do you get exactly?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-08-28 04:29:16 | Re: [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1? |
Previous Message | Arnold Putong | 2002-08-28 04:03:05 | SERIAL parameters |