[
https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493807
]
A B commented on DERBY-1816:
----------------------------
Thank you for the link, Dan, it's very helpful.
Since all of the changes that I've made in the clean_v1 patch happen for the
getXXX() methods that do not take a Calendar argument, my reading is that the
values should be set "according to the time zone of the java virtual machine".
My assumption is that this is what happens with the default "new
java.util.GregorianCalendar()" constructor, in which case the changes are fine.
Note that for getXXX() methods which *do* take a Calendar object, the client
code first calls the version of the method that takes no arguments (which is
what the cleanup_v1 patch affects) and then normalizes the result based on the
timezone of the received Calendar object. So I think that part should be
working correctly, as well.
Please let me know if I've misread something, though...
Thanks again for the pointer.
> 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.
