db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-1816) Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
Date Wed, 23 May 2007 22:06:17 GMT

     [ 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

  27 del
  < Max threads changed to 9000.
  >  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:,,,,
>            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
> 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));      <<<<<<<<<<<<<
>     }

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message