[ https://issues.apache.org/jira/browse/DERBY-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-4810:
--------------------------------------
Attachment: derby-4810-1a.diff
The attached patch makes the two method behave the same way, and also makes the network client
behave the same way as the embedded driver. DateTimeTest runs cleanly, but I haven't run any
other tests on the patch yet.
> 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: derby-4810-1a.diff, 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.
|