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: http://issues.apache.org/jira/browse/DERBY-1816
Project: Derby
Issue Type: Bug
Components: JDBC, Network Client
Affects Versions: 10.1.3.1, 10.1.3.0, 10.1.2.1, 10.1.1.0, 10.2.1.0, 10.3.0.0
Reporter: Daniel John Debrunner
Priority: Minor
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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
