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 21:57:15 GMT

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

A B commented on DERBY-1816:

> So I think the embedded behaviour is within the spec. In fact one might be able to read
> spec in such a way that it is expected the passed in Calendar object is modified by the
> and set to the value corresponding to the column, thus maybe client behaviour is incorrect?

Hmm.  So we are to read "object to use in constructing the date" as "object in which to return
the constructed date"?

Seems odd to a) return the timestamp value as a java.sql.Timestamp, *and* b) return the timestamp
via the received Calendar object.

If that is in fact the correct behavior, then is there a bug in embedded because it truncates
the milliseconds? I.e.:

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) 

Note how the "targetAfter" object has no milliseconds.

For what it's worth, I ran the exact same program against a DB2 database and, as with Derby
client, the Calendar object is *not* modified.  I don't have any other RDMBs against which
to try...

In any event, I think this discussion goes beyond the scope of the "recyclableCleanup_v1.patch",
which is targeted for a very specific type of cleanup--and one that does not itself alter
functionality.  Maybe changes to way in which client handles Calendar objects can be filed
as a separate issue?

> 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