Thread: issues with Statement.getTimestamp(int, Calendar)
Dear PSQL-JDBC team, There is a issue with Statement.getTimestamp(int, Calendar). The timestamp is offset in the wrong direction. The quivalent on ResultSet.getTimestamp(int, Calendar) works fine. Is this a known bug, can we expect a fix for this, when? Thanks Ravi ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com
Ravi Periasamy wrote: > Dear PSQL-JDBC team, > > There is a issue with Statement.getTimestamp(int, > Calendar). The timestamp is offset in the wrong > direction. > > The quivalent on ResultSet.getTimestamp(int, Calendar) > works fine. > > Is this a known bug, can we expect a fix for this, > when? Can you send a testcase demonstrating the problem please? -O
The test case is as follows.
I created a function as follows:
==================================================
create or replace function testouttimestamp(OUT a1
timestamp) AS $$
begin
a1 := '1970-01-01 00:00:00';
end;
$$ language plpgsql;
==================================================
and called through JDBC as follows:
==================================================
TimeZone tz = TimeZone.getTimeZone("GMT");
Calendar cr = Calendar.getInstance(tz);
CallableStatement stmt = con.prepareCall( "{call
testouttimestamp(?)}");
stmt.registerOutParameter(1, Types.TIMESTAMP);
stmt.execute();
Timestamp ts = stmt.getTimestamp(1, cr);
System.out.println("ts = " + ts);
==================================================
Actual Result ==>
1969-12-31 18:30:00.0
Expected Result ==>
1970-01-01 05:30:00.0
Note: ResultSet.getTimestamp(int, Calendar) works
fine.
Thanks
Ravi
--- Oliver Jowett <oliver@opencloud.com> wrote:
> Ravi Periasamy wrote:
> > Dear PSQL-JDBC team,
> >
> > There is a issue with Statement.getTimestamp(int,
> > Calendar). The timestamp is offset in the wrong
> > direction.
> >
> > The quivalent on ResultSet.getTimestamp(int,
> Calendar)
> > works fine.
> >
> > Is this a known bug, can we expect a fix for this,
> > when?
>
> Can you send a testcase demonstrating the problem
> please?
>
> -O
>
____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index
Ravi,
what is your time zone from what you have my guess would be -9:00 ?
I think the JVM adjusts the actual time to your local timezone when
it prints it.
Dave
On 12-Dec-06, at 11:05 PM, Ravi Periasamy wrote:
> The test case is as follows.
>
> I created a function as follows:
> ==================================================
> create or replace function testouttimestamp(OUT a1
> timestamp) AS $$
> begin
> a1 := '1970-01-01 00:00:00';
> end;
> $$ language plpgsql;
> ==================================================
>
> and called through JDBC as follows:
> ==================================================
> TimeZone tz = TimeZone.getTimeZone("GMT");
> Calendar cr = Calendar.getInstance(tz);
> CallableStatement stmt = con.prepareCall( "{call
> testouttimestamp(?)}");
> stmt.registerOutParameter(1, Types.TIMESTAMP);
> stmt.execute();
> Timestamp ts = stmt.getTimestamp(1, cr);
> System.out.println("ts = " + ts);
> ==================================================
>
> Actual Result ==>
> 1969-12-31 18:30:00.0
>
> Expected Result ==>
> 1970-01-01 05:30:00.0
>
> Note: ResultSet.getTimestamp(int, Calendar) works
> fine.
>
> Thanks
> Ravi
>
> --- Oliver Jowett <oliver@opencloud.com> wrote:
>
>> Ravi Periasamy wrote:
>>> Dear PSQL-JDBC team,
>>>
>>> There is a issue with Statement.getTimestamp(int,
>>> Calendar). The timestamp is offset in the wrong
>>> direction.
>>>
>>> The quivalent on ResultSet.getTimestamp(int,
>> Calendar)
>>> works fine.
>>>
>>> Is this a known bug, can we expect a fix for this,
>>> when?
>>
>> Can you send a testcase demonstrating the problem
>> please?
>>
>> -O
>>
>
>
>
>
> ______________________________________________________________________
> ______________
> Want to start your own business?
> Learn how on Yahoo! Small Business.
> http://smallbusiness.yahoo.com/r-index
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
Dave,
I'm in Asia/Calcutta (India) time zone. It is +5.30
from GMT.
I'm almost certain there's a bug in
Statement.getTimestamp(int, Calendar). Where as,
Resultset.getTimestamp(int, Calendar) gives the
correct value.
I suspect the AbstractJdbc2Statement.changetime()
method.
Thanks
Ravi
--- Dave Cramer <pg@fastcrypt.com> wrote:
> Ravi,
>
> what is your time zone from what you have my guess
> would be -9:00 ?
>
> I think the JVM adjusts the actual time to your
> local timezone when
> it prints it.
>
> Dave
> On 12-Dec-06, at 11:05 PM, Ravi Periasamy wrote:
>
> > The test case is as follows.
> >
> > I created a function as follows:
> > ==================================================
> > create or replace function testouttimestamp(OUT a1
> > timestamp) AS $$
> > begin
> > a1 := '1970-01-01 00:00:00';
> > end;
> > $$ language plpgsql;
> > ==================================================
> >
> > and called through JDBC as follows:
> > ==================================================
> > TimeZone tz = TimeZone.getTimeZone("GMT");
> > Calendar cr = Calendar.getInstance(tz);
> > CallableStatement stmt = con.prepareCall( "{call
> > testouttimestamp(?)}");
> > stmt.registerOutParameter(1, Types.TIMESTAMP);
> > stmt.execute();
> > Timestamp ts = stmt.getTimestamp(1, cr);
> > System.out.println("ts = " + ts);
> > ==================================================
> >
> > Actual Result ==>
> > 1969-12-31 18:30:00.0
> >
> > Expected Result ==>
> > 1970-01-01 05:30:00.0
> >
> > Note: ResultSet.getTimestamp(int, Calendar) works
> > fine.
> >
> > Thanks
> > Ravi
> >
> > --- Oliver Jowett <oliver@opencloud.com> wrote:
> >
> >> Ravi Periasamy wrote:
> >>> Dear PSQL-JDBC team,
> >>>
> >>> There is a issue with
> Statement.getTimestamp(int,
> >>> Calendar). The timestamp is offset in the wrong
> >>> direction.
> >>>
> >>> The quivalent on ResultSet.getTimestamp(int,
> >> Calendar)
> >>> works fine.
> >>>
> >>> Is this a known bug, can we expect a fix for
> this,
> >>> when?
> >>
> >> Can you send a testcase demonstrating the problem
> >> please?
> >>
> >> -O
> >>
> >
> >
> >
> >
> >
>
______________________________________________________________________
>
> > ______________
> > Want to start your own business?
> > Learn how on Yahoo! Small Business.
> > http://smallbusiness.yahoo.com/r-index
> >
> > ---------------------------(end of
> > broadcast)---------------------------
> > TIP 4: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
>
>
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
Ravi Periasamy wrote: > I suspect the AbstractJdbc2Statement.changetime() > method. Yeah, that code looks pretty broken to me, it has completely the wrong end of the stick about what it should be doing with the provided calendar, AFAICS. Dave, why doesn't the out-parameter stuff do timestamp conversion by delegating to the same code as the ResultSet code uses? That does all the hard stuff for you.. -O
Oliver, To be honest, I didn't write the stuff in AbstractJdbc2Statement. That is left over from the original implementation. That being said, there is no function in the utils that takes a date and a calendar and returns a Calendar. It does look like the best place to put that code though. Dave On 13-Dec-06, at 7:28 AM, Oliver Jowett wrote: > Ravi Periasamy wrote: > >> I suspect the AbstractJdbc2Statement.changetime() >> method. > > Yeah, that code looks pretty broken to me, it has completely the > wrong end of the stick about what it should be doing with the > provided calendar, AFAICS. > > Dave, why doesn't the out-parameter stuff do timestamp conversion > by delegating to the same code as the ResultSet code uses? That > does all the hard stuff for you.. > > -O >
On Wed, 13 Dec 2006, Oliver Jowett wrote: > Ravi Periasamy wrote: > >> I suspect the AbstractJdbc2Statement.changetime() >> method. > > Yeah, that code looks pretty broken to me, it has completely the wrong > end of the stick about what it should be doing with the provided > calendar, AFAICS. > > Dave, why doesn't the out-parameter stuff do timestamp conversion by > delegating to the same code as the ResultSet code uses? That does all > the hard stuff for you.. > I've rewritten this code to farm out the work to TimestampUtils and applied it to the 8.1, 8.2 and 8.3dev branches. Kris Jurka
We worked around this issue. I'm keen to pick up a official release of the JDBC driver with the fix, will there be one anytime soon? Thanks Ravi --- Kris Jurka <books@ejurka.com> wrote: > > > On Wed, 13 Dec 2006, Oliver Jowett wrote: > > > Ravi Periasamy wrote: > > > >> I suspect the AbstractJdbc2Statement.changetime() > >> method. > > > > Yeah, that code looks pretty broken to me, it has > completely the wrong > > end of the stick about what it should be doing > with the provided > > calendar, AFAICS. > > > > Dave, why doesn't the out-parameter stuff do > timestamp conversion by > > delegating to the same code as the ResultSet code > uses? That does all > > the hard stuff for you.. > > > > I've rewritten this code to farm out the work to > TimestampUtils and > applied it to the 8.1, 8.2 and 8.3dev branches. > > Kris Jurka > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Fri, 5 Jan 2007, Ravi Periasamy wrote: > We worked around this issue. I'm keen to pick up a > official release of the JDBC driver with the fix, will > there be one anytime soon? > I don't have any immediate plans for one as there are still a fair number of open issues that I'm dealing with. If you'd like to test the fixes I've made you can pull them from CVS or try this jar file here: http://ejurka.com/pgsql/jars/rp/ Kris Jurka