Re: Calculation Error on Epoch?

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

In response to

Browse pgsql-sql by date

  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