RE: RE: JDBC Timestamp Problem - Mailing list pgsql-interfaces

From Peter Mount
Subject RE: RE: JDBC Timestamp Problem
Date
Msg-id 1B3D5E532D18D311861A00600865478CF1B655@exchange1.nt.maidstone.gov.uk
Whole thread Raw
In response to JDBC Timestamp Problem  (yves@asua.vlaanderen.net)
List pgsql-interfaces

-- 
Peter Mount
Enterprise Support Officer, Maidstone Borough Council
Email: petermount@maidstone.gov.uk
WWW: http://www.maidstone.gov.uk
All views expressed within this email are not the views of Maidstone Borough
Council


> -----Original Message-----
> From: Thomas Lockhart [mailto:lockhart@alumni.caltech.edu]
> Sent: Tuesday, December 12, 2000 3:28 PM
> To: Peter Mount
> Cc: 'pgsql-interfaces@postgresql.org'
> Subject: Re: [INTERFACES] RE: JDBC Timestamp Problem
> 
> 
> > Yes, about 1-2 months ago ;-) The current CVS has the patch applied.
> > As soon as I get the domain problems sorted, I'm going to 
> tripple check
> > Timestamp as I'd like to see the next release without the 
> timestamp bug
> > reappearing...
> 
> Do you want to talk about what PostgreSQL *should* return for
> timestamp values? Currently, it rounds to two digits if there
> is a non-zero fractional part, and omits the fractional part
> otherwise.

It might be an idea... getTimestamp() seemed to break when 7.0 was released.
I've had so many different methods sent to me about how to check for it,
I've so far ended up picking the simplest of them. If we can sort out what
Timestamp returns then may be we can get rid of this problem for good.

Currently, JDBC switches datestyle to ISO so that all the date routines have
the same format. One suggestion was to switch from ISO to Postgres but I'm
worried if anyone else out there has code that relies on it running with
ISO, in which case the change would break them.

> Both features are there for readability and to eliminate the 
> possibility
> of accumulated rounding errors introducing "lots 'o nines" in the
> output. But we *could* make it variable length or do more checking and
> rounding in a different way. And we *could* at least have a SET
> key=value parameter which you could use to guarantee a format for a
> session.
> 
> The fact that JDBC has troubles with the current scheme means that
> others are probably having trouble too...

I think the other main one that would be affected would be ODBC as both
API's tend to mirror what they do, and I suspect they have an equivalent of
getTimestamp();

Peter


pgsql-interfaces by date:

Previous
From: Philip Crotwell
Date:
Subject: JDBC, Timestamp and getting microseconds
Next
From: "Nico Kretschmar"
Date:
Subject: PostgreSQL via ODBC and Approach