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] Commented: (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 Thu, 10 May 2007 20:47:15 GMT

    [ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494830
] 

A B commented on DERBY-1816:
----------------------------

One solution that seems to solve this problem is to create a java.sql.Timestamp object from
the SQL TIMESTAMP and then use the "Time(long time)" constructor to create a java.sql.Time
object, where "time" is retrieved from the java.sql.Timestamp object.  For example (in client/am/DateTime.java):

     java.sql.Time result = new java.sql.Time(timestampBytesToTimestamp(
         buffer, offset, (java.sql.Timestamp)null, encoding).getTime());

That said, though, Java API indicates the following:

  "The date components should be set to the "zero epoch" value of January 1, 1970 and should
not be accessed."

So we would have to explicitly override the date fields for the resultant java.sql.Time object.
 Doing so directly via the Time object would require use of deprecated methods (setYear(),
setMonth(), setDay()).  The other (recommended) option is to use an intermediary Calendar
object:

     java.sql.Timestamp ts = timestampBytesToTimestamp(
         buffer, offset, (java.sql.Timestamp)null, encoding).getTime());

     Calendar cal = <cleared Calendar object>;
     cal.setTimeInMillis(ts.getTime());
 
     /* Java API indicates that the date components of a Time value must
      * be set to January 1, 1970.
      */
     cal.set(1970, Calendar.JANUARY, 1);
     return new java.sql.Time(cal.getTimeInMillis());

The latter approach (use of Calendar) seems cleaner, but requires either 1) repeated instantiation
of a Calendar object, or 2) re-use of some passed in Calendar object, per d1816_recyclableCleanup_v1.patch.
 The former approach (use of deprecated setXXX() methods) requires fewer changes but seems
less wholesome.

Any votes for/against one or the other?

I prefer to use the Calendar approach to avoid deprecated methods, which is why I would like
to commit the recyclableCleanup_v1.patch.  But I'm open to alternate suggestions.

Either approach requires the additional instantion of a java.sql.Timestamp object for each
call to getTime().  Is that acceptable?  We could avoid that by isolating the timestamp parsing
code into its own method and returning its fields via an array, but I'm not sure if that's
better or worse than creating an intermediate Timestamp object...

> 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.


Mime
View raw message