[
https://issues.apache.org/jira/browse/DERBY-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-4810:
--------------------------------------
Attachment: test.diff
Attaching a test case that demonstrates the difference.
Fails with:
1)
testTrailingZeros(org.apache.derbyTesting.functionTests.tests.lang.DateTimeTest)junit.framework.AssertionFailedError:
Column value mismatch @ column '1', row 1:
Expected: >2010-09-22 14:40:33.012<
Found: >2010-09-22 14:40:33.012000000<
> setTimestamp() methods don't agree on trailing zeros
> ----------------------------------------------------
>
> Key: DERBY-4810
> URL: https://issues.apache.org/jira/browse/DERBY-4810
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Attachments: test.diff
>
>
> With the statement
> VALUES CAST(? AS VARCHAR(29))
> PreparedStatement.setTimestamp(int,Timestamp) and
> PreparedStatement.setTimestamp(int,Timestamp,Calendar) don't agree on what to
> do with trailing zeros in the nanosecond component. The method that doesn't
> take a Calendar argument, removes trailing zeros. The method that takes a
> Calendar object appends zeros so that the nanosecond component always has
> nine digits. (Both methods have a special case when nanoseconds is zero, and
> they agree on adding just a single zero after the decimal point in that case.)
> The format used by PreparedStatement.setTimestamp(int,Timestamp) matches what
> java.sql.Timestamp.toString() returns (in fact, it uses Timestamp.toString()
> internally to produce the string representation), and I think it would be
> reasonable to use that format for both the methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
