[
https://issues.apache.org/jira/browse/DERBY-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493814
]
A B commented on DERBY-2602:
----------------------------
For what little it may be worth, code comments in client/am/PreparedStatement
seem to suggest that this truncation was intentional (or at least, known) at
"set" time:
~line 873:
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."));
Of course the warning that's commented out refers to "rounding", which isn't
quite right--we actually truncate.
May be relevant, maybe not.
> 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.
