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