Derby
  1. Derby
  2. DERBY-4810

setTimestamp() methods don't agree on trailing zeros

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.7.1.1
    • Fix Version/s: 10.7.1.1
    • Component/s: SQL
    • Labels:
      None
    • Bug behavior facts:
      Embedded/Client difference

      Description

      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.

      1. test.diff
        2 kB
        Knut Anders Hatlen
      2. derby-4810-1a.diff
        4 kB
        Knut Anders Hatlen

        Activity

        Hide
        Knut Anders Hatlen added a comment -

        Committed revision 1000811.

        Show
        Knut Anders Hatlen added a comment - Committed revision 1000811.
        Hide
        Knut Anders Hatlen added a comment -

        All the regression tests ran cleanly with the patch.

        Show
        Knut Anders Hatlen added a comment - All the regression tests ran cleanly with the patch.
        Hide
        Knut Anders Hatlen added a comment -

        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.

        Show
        Knut Anders Hatlen added a comment - 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.
        Hide
        Knut Anders Hatlen added a comment -

        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<

        Show
        Knut Anders Hatlen added a comment - 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<
        Hide
        Knut Anders Hatlen added a comment -

        Marking as an Embedded/Client difference too, since the client driver will always use the format of setTimestamp(int,Timestamp,Calendar).

        Show
        Knut Anders Hatlen added a comment - Marking as an Embedded/Client difference too, since the client driver will always use the format of setTimestamp(int,Timestamp,Calendar).

          People

          • Assignee:
            Knut Anders Hatlen
            Reporter:
            Knut Anders Hatlen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development