db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1816) Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
Date Mon, 07 May 2007 18:21:15 GMT

    [ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494101

A B commented on DERBY-1816:

> any idea why they don't just use the calendar passed in and just perform the conversion
> I think that's what embedded does.

I looked at the differences between embedded and client and while I'm not sure what the answer
to your question is (i.e. why client doesn't "just use the calendar passed in") I did notice
a difference in behavior that struck me as noteworthy.

Namely, when a call to a getXXX() date/time method is made and a Calendar object is passed
in, embedded will clobber (or at least wipe out) the received Calendar argument's value. 
With the client, though, the argument is preserved (which is more what I would have expected).

So while I can look into making the client mimic the embedded behavior, I'm not sure that
this particular piece of behavior (clobbering the Calendar argument's value) is correct.

Ex: If "rs" is a ResultSet whose first column is the TIMESTAMP value "2007-05-03 16:49:52.883"
then a call to the "assertGetWithCal()" method below will return something similar to the

On embedded:

 targetBefore -=> 9 10, 2010 -- 10:10:10.205 (GMT-10:00)
 got cal     -=> 4 3, 2007 -- 19:49:52.883 (America/Los_Angeles)
 targetAfter -=> 4 3, 2007 -- 16:49:52.0 (GMT-10:00)

With client:

 targetBefore -=> 9 10, 2010 -- 10:10:10.607 (GMT-10:00)
 got cal     -=> 4 3, 2007 -- 19:49:52.883 (America/Los_Angeles)
 targetAfter -=> 9 10, 2010 -- 10:10:10.607 (GMT-10:00)

Notice how, with embedded, "targetAfter" has the same year, month, day, and time as the result
of the "getTimestamp(Calendar)" call, and also that the millisecond value has been wiped out.
 But with client, "targetAfter" matches "targetBefore".  In both cases the correct timezone
adjustment takes place.

My guess is that the embedded behavior is incorrect, but I'm not confident enough to say for

Any other opinions?

> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution
and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-1816
>                 URL: https://issues.apache.org/jira/browse/DERBY-1816
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC, Network Client
>    Affects Versions:,,,,
>            Reporter: Daniel John Debrunner
>         Assigned To: A B
>            Priority: Minor
>         Attachments: d1816_recycleCleanup_v1.patch
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP
object has its millisecond value for the time portion equal to that for the java.sql.Timestamp
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond
 value is always zero,
> but java.sql.Time  is not a direct mapping to the SQL Type, it's a JDBC type, so when
converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of
its calls will be commented out
> with a comment with this bug number.
>     private void assertTimeEqual(Time tv, Timestamp tsv)
>     {
>         cal.clear();
>         cal.setTime(tv);
>         int hour = cal.get(Calendar.HOUR_OF_DAY);
>         int min = cal.get(Calendar.MINUTE);
>         int sec = cal.get(Calendar.SECOND);
>         int ms = cal.get(Calendar.MILLISECOND);
>         // Check the time portion is set to the same as tv
>         cal.clear();
>         cal.setTime(tsv);
>         assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
>         assertEquals(min, cal.get(Calendar.MINUTE));
>         assertEquals(sec, cal.get(Calendar.SECOND));
>         assertEquals(ms, cal.get(Calendar.MILLISECOND));      <<<<<<<<<<<<<
>     }

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message