[
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 once?
> 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 following:
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 sure.
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: 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.
