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 Tue, 08 May 2007 15:19:15 GMT

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

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

Thank you for your extensive comments on this, Dan!

> Looking at the network client's implementation of getTimeStamp() with a Calendar I have
to 
> say it seems inefficient, confusing 

I definitely agree with you here!

> and wrong. :-)

Well...okay.  Do you by chance know of a concrete repro to demonstrate what you have described
above?

> What is required is the same approach as embedded, which is to always perform
>   YYYY-MM-DD:hh:mm:ss.ffff >> Calendar >> long milli-seconds >> java.sql.Timestamp


Sounds like a separate Jira, agreed?

Is it okay to proceed with committing the recyclableCleanup_v1.patch (and subquent fix) for
this issue as it is now?  I don't think my changes make the situation any worse, and they
will make it easier to resolve this issue--and also DERBY-889, I believe.

Unless I hear objections pretty quickly, I'll plan to commit the cleanup_v1 patch later this
morning.

> 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