[
https://issues.apache.org/jira/browse/DERBY-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493500
]
Daniel John Debrunner commented on DERBY-2602:
----------------------------------------------
I don't think DERBY-2602 and DERBY-1816 are the same issue.
DERBY-1816 - SQL TIMESTAMP column to java.sql.Time object via RS.getTime() has
a zero milli-seconds value.
DERBY-2602 - SQL TIMESTAMP column to java.sql.Timestamp object via
RS.getTimestamp() has a truncated, but non-zero, nano-seconds value.
If they were the same I would expect 2602 to show a zero value for the
factional second part.
> TIMESTAMP value is truncated when return to client
> ---------------------------------------------------
>
> Key: DERBY-2602
> URL: https://issues.apache.org/jira/browse/DERBY-2602
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.3.0.0
> Reporter: Kathey Marsden
> Priority: Minor
> Attachments: d2602.java
>
>
> In ParameterMappingTest I see the following differences between embedded
> and client. Client is truncating the TIMESTAMP value. Look for this bug
> number in the test for reproduction.
> case java.sql.Types.TIMESTAMP:
> if (param == 2)
> if (usingEmbedded())
> assertEquals("2004-03-12 21:14:24.938222433",
> val.toString());
> else
> assertEquals("2004-03-12 21:14:24.938222",
> val.toString());
> else if (param == 3)
> if (usingEmbedded())
> assertEquals("2004-04-12 04:25:26.462983731",
> val.toString());
> else
> assertEquals("2004-04-12 04:25:26.462983",
> val.toString());
> break;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
