RE: RE: JDBC Timestamp Problem

Поиск
Список
Период
Сортировка
От Peter Mount
Тема RE: RE: JDBC Timestamp Problem
Дата
Msg-id 1B3D5E532D18D311861A00600865478CF1B655@exchange1.nt.maidstone.gov.uk
обсуждение исходный текст
Ответ на JDBC Timestamp Problem  (yves@asua.vlaanderen.net)
Список 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 по дате отправления:

Предыдущее
От: Philip Crotwell
Дата:
Сообщение: JDBC, Timestamp and getting microseconds
Следующее
От: "Nico Kretschmar"
Дата:
Сообщение: PostgreSQL via ODBC and Approach