[
https://issues.apache.org/jira/browse/DERBY-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542771
]
Mayuresh Nirhali commented on DERBY-2602:
-----------------------------------------
A quick look at client/amt/PreparedStatement:setTimestamp(int parameterIndex,
java.sql.Timestamp x) showed following comment,
setInput(parameterIndex, x);
// once the nanosecond field of timestamp is trim to
microsecond for DERBY, should we throw a warning
//if (getParameterType (parameterIndex) ==
java.sql.Types.TIMESTAMP && x.getNanos() % 1000 != 0)
// accumulateWarning (new SqlWarning (agent_.logWriter_,
"DERBY timestamp can only store up to microsecond, conversion from nanosecond
to microsecond causes rounding."));
There seems to be some reason for trimming here. Before going further, I would
like to know if anyone knows why it was done this way ????
> 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.1.4
> Reporter: Kathey Marsden
> Assignee: Mayuresh Nirhali
> 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.
