[
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 the
> spec in such a way that it is expected the passed in Calendar object is
> modified by the call
> 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: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
> 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 value.
> 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)); <<<<<<<<<<<<<
> FAILS HERE
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
