[
https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A B updated DERBY-1816:
-----------------------
Attachment: d1816_v1.patch
Attaching d1816_v1.patch, which is a fix for this issue. The patch does the
following:
1. Separates the timestamp parse logic in client/am/DateTime.java into a new
method called "parseTimestampString()". The new method takes a timestamp
string and a Calendar object, and sets the fields of the Calendar based on
the fields that are parsed from the timestamp string. (This is, I think,
what Dan was suggesting in his most recent comment). The method also
returns the parsed microseconds value since that cannot be set on a
Calendar object (the precision of a Calendar is milliseconds).
2. Modifies timestampBytesToTimestamp(...) to call the new method for
parsing timestamps.
3. Changes the timestampBytesToTime(...) method so that it now parses the
*full* timestamp (via the new parseTimestampString() method) instead of
just parsing the hours, minutes, and seconds. Then a java.sql.Time
object is created from the Calendar object into which the timestamp
string was parsed. This allows us to preserve the sub-second resolution
that is parsed from the timestamp.
4. Re-enables the relevant test case in lang/TimeHandlingTest.java so that
it now runs in client mode.
I ran derbyall and suites.All on a SUSE Linux machine with an earlier version
of this patch and the only failure was in derbyall/derbynetmats/maxthreads,
which failed with the following diff:
27 del
< Max threads changed to 9000.
27a27
> Reading from process streams timed out..
I don't think that is related to my changes, though.
If anyone has feedback on this fix/approach, that would be great. I plan to
re-run derbyall and suites.All as a sanity check to make sure the latest
version (_v1 as attached here) still runs cleanly, but am open to suggestions
in the meantime...
> 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,
> d1816_recycleCleanup_v2.patch, d1816_recycleCleanup_v2.stat,
> d1816_recycleCleanup_v3.patch, d1816_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.
