Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id D4D35475FDE for ; Wed, 28 Aug 2002 00:14:37 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 422BA475DCA for ; Wed, 28 Aug 2002 00:14:37 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g7S4EdZM017503; Wed, 28 Aug 2002 00:14:39 -0400 (EDT) To: "Josh Berkus" Cc: pgsql-sql@postgresql.org, Thomas Lockhart Subject: Re: Calculation Error on Epoch? In-reply-to: References: Comments: In-reply-to "Josh Berkus" message dated "Tue, 27 Aug 2002 20:30:32 -0700" Date: Wed, 28 Aug 2002 00:14:38 -0400 Message-ID: <17502.1030508078@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200208/375 X-Sequence-Number: 9221 "Josh Berkus" 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