Received: from golem.jpl.nasa.gov (IDENT:postfix@dialin-109.jpl.nasa.gov
	[128.149.231.109])
	by hub.org (8.10.1/8.10.1) with ESMTP id e75NRBG82826
	for <pgsql-interfaces@postgresql.org>;
	Sat, 5 Aug 2000 19:27:12 -0400 (EDT)
Received: from alumni.caltech.edu (localhost.localdomain [127.0.0.1])
	by golem.jpl.nasa.gov (Postfix) with ESMTP
	id ACBAB7F0B; Sat,  5 Aug 2000 23:30:10 +0000 (UTC)
Message-ID: <398CA382.390904BB@alumni.caltech.edu>
Date: Sat, 05 Aug 2000 23:30:10 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
Organization: Yes
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Mount <petermount@it.maidstone.gov.uk>
Cc: "'Chris Ryan'" <chris@greatbridge.com>, pgsql-interfaces@postgresql.org
Subject: Re: JDBC and Timestamps
References: 
 <1B3D5E532D18D311861A00600865478CF1B1E4@exchange1.nt.maidstone.gov.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Archive-Number: 200008/52

> ... I'm noticing problems with the timestamp fields. The JDBC
> driver when writing a Timestamp value to postgres is passing the value
> to the backend as a String in the following format "yyyy-mm-dd
> hh:mm:ss.fffffffff" <-- the last part .fffffffff is nanosecs.

Do you actually need nanosecond (or sub-microsecond) resolution? At the
moment, Postgres rounds internal values *and* truncates printed results
to avoid accumulating internal roundoff errors. But I did that pretty
conservatively, rather than actually testing to see if it could carry
more precision.

If you want to test with more precision, we could try some variations...

                  - Thomas