Derby
  1. Derby
  2. DERBY-4626

Timestamp truncated when converted to string with explicit calendar

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.5.3.0
    • Fix Version/s: 10.5.3.2, 10.6.2.4, 10.7.1.1
    • Component/s: SQL
    • Labels:
      None
    • Bug behavior facts:
      Wrong query result

      Description

      When setting the value of a VARCHAR parameter with setTimestamp() the timestamp is truncated to microsecond resolution if a calendar is specified. Nanosecond resolution is preserved when a calendar is not specified. These two methods should behave the same way. Since Derby supports nanosecond resolution, the timestamps should not be truncated.

      1. test.diff
        2 kB
        Knut Anders Hatlen
      2. TimestampToVarchar.java
        1 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Knut Anders Hatlen created issue -
          Knut Anders Hatlen made changes -
          Field Original Value New Value
          Link This issue is related to DERBY-4625 [ DERBY-4625 ]
          Hide
          Knut Anders Hatlen added a comment -

          The attached class, TimestampToVarchar, shows the difference between the two methods. Note these two differences:

          1) The setTimestamp() method that takes a Calendar truncates nanoseconds so that the resulting resolution is microseconds. The method that doesn't take a Calendar preserves the nanoseconds.

          2) The setTimestamp() method that takes a Calendar does not remove trailing zeros, whereas the method that doesn't take a Calendar does remove trailing zeros (except if the fraction is zero).

          Here's the output of the repro on trunk:

          Testing timestamp: 2010-04-20 15:17:36.123456789

          • without calendar: 2010-04-20 15:17:36.123456789
          • with calendar: 2010-04-20 15:17:36.123457

          Testing timestamp: 2010-04-20 15:17:36.12345678

          • without calendar: 2010-04-20 15:17:36.12345678
          • with calendar: 2010-04-20 15:17:36.123457

          Testing timestamp: 2010-04-20 15:17:36.1234567

          • without calendar: 2010-04-20 15:17:36.1234567
          • with calendar: 2010-04-20 15:17:36.123457

          Testing timestamp: 2010-04-20 15:17:36.123456

          • without calendar: 2010-04-20 15:17:36.123456
          • with calendar: 2010-04-20 15:17:36.123456

          Testing timestamp: 2010-04-20 15:17:36.12345

          • without calendar: 2010-04-20 15:17:36.12345
          • with calendar: 2010-04-20 15:17:36.123450

          Testing timestamp: 2010-04-20 15:17:36.1234

          • without calendar: 2010-04-20 15:17:36.1234
          • with calendar: 2010-04-20 15:17:36.123400

          Testing timestamp: 2010-04-20 15:17:36.123

          • without calendar: 2010-04-20 15:17:36.123
          • with calendar: 2010-04-20 15:17:36.123000

          Testing timestamp: 2010-04-20 15:17:36.12

          • without calendar: 2010-04-20 15:17:36.12
          • with calendar: 2010-04-20 15:17:36.120000

          Testing timestamp: 2010-04-20 15:17:36.1

          • without calendar: 2010-04-20 15:17:36.1
          • with calendar: 2010-04-20 15:17:36.100000

          Testing timestamp: 2010-04-20 15:17:36.0

          • without calendar: 2010-04-20 15:17:36.0
          • with calendar: 2010-04-20 15:17:36.0
          Show
          Knut Anders Hatlen added a comment - The attached class, TimestampToVarchar, shows the difference between the two methods. Note these two differences: 1) The setTimestamp() method that takes a Calendar truncates nanoseconds so that the resulting resolution is microseconds. The method that doesn't take a Calendar preserves the nanoseconds. 2) The setTimestamp() method that takes a Calendar does not remove trailing zeros, whereas the method that doesn't take a Calendar does remove trailing zeros (except if the fraction is zero). Here's the output of the repro on trunk: Testing timestamp: 2010-04-20 15:17:36.123456789 without calendar: 2010-04-20 15:17:36.123456789 with calendar: 2010-04-20 15:17:36.123457 Testing timestamp: 2010-04-20 15:17:36.12345678 without calendar: 2010-04-20 15:17:36.12345678 with calendar: 2010-04-20 15:17:36.123457 Testing timestamp: 2010-04-20 15:17:36.1234567 without calendar: 2010-04-20 15:17:36.1234567 with calendar: 2010-04-20 15:17:36.123457 Testing timestamp: 2010-04-20 15:17:36.123456 without calendar: 2010-04-20 15:17:36.123456 with calendar: 2010-04-20 15:17:36.123456 Testing timestamp: 2010-04-20 15:17:36.12345 without calendar: 2010-04-20 15:17:36.12345 with calendar: 2010-04-20 15:17:36.123450 Testing timestamp: 2010-04-20 15:17:36.1234 without calendar: 2010-04-20 15:17:36.1234 with calendar: 2010-04-20 15:17:36.123400 Testing timestamp: 2010-04-20 15:17:36.123 without calendar: 2010-04-20 15:17:36.123 with calendar: 2010-04-20 15:17:36.123000 Testing timestamp: 2010-04-20 15:17:36.12 without calendar: 2010-04-20 15:17:36.12 with calendar: 2010-04-20 15:17:36.120000 Testing timestamp: 2010-04-20 15:17:36.1 without calendar: 2010-04-20 15:17:36.1 with calendar: 2010-04-20 15:17:36.100000 Testing timestamp: 2010-04-20 15:17:36.0 without calendar: 2010-04-20 15:17:36.0 with calendar: 2010-04-20 15:17:36.0
          Knut Anders Hatlen made changes -
          Attachment TimestampToVarchar.java [ 12442417 ]
          Knut Anders Hatlen made changes -
          Issue & fix info [Repro attached]
          Knut Anders Hatlen made changes -
          Link This issue is related to DERBY-4614 [ DERBY-4614 ]
          Knut Anders Hatlen made changes -
          Link This issue relates to DERBY-2602 [ DERBY-2602 ]
          Nirmal Fernando made changes -
          Assignee C.S. Nirmal J. Fernando [ nirmal ]
          Hide
          Knut Anders Hatlen added a comment -

          The fix for DERBY-4625 also fixed this issue. I've added a regression test case in DateTimeTest to verify the fix. Committed revision 999485.

          Show
          Knut Anders Hatlen added a comment - The fix for DERBY-4625 also fixed this issue. I've added a regression test case in DateTimeTest to verify the fix. Committed revision 999485.
          Knut Anders Hatlen made changes -
          Attachment test.diff [ 12455155 ]
          Knut Anders Hatlen made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Fix Version/s 10.7.0.0 [ 12314971 ]
          Resolution Fixed [ 1 ]
          Rick Hillegas made changes -
          Fix Version/s 10.7.1.1 [ 12315564 ]
          Fix Version/s 10.7.1.0 [ 12314971 ]
          Nirmal Fernando made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Nirmal Fernando made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Issue & fix info [Repro attached]
          Resolution Fixed [ 1 ]
          Kathey Marsden made changes -
          Link This issue is required by DERBY-4994 [ DERBY-4994 ]
          Knut Anders Hatlen made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Hide
          Kathey Marsden added a comment -

          Reopen for backport

          Show
          Kathey Marsden added a comment - Reopen for backport
          Kathey Marsden made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Hide
          Mike Matrigali added a comment -

          temp taking ownership to backport to 10.6 and 10.5

          Show
          Mike Matrigali added a comment - temp taking ownership to backport to 10.6 and 10.5
          Mike Matrigali made changes -
          Assignee C.S. Nirmal J. Fernando [ nirmal ] Mike Matrigali [ mikem ]
          Hide
          Mike Matrigali added a comment -

          backported fix from trunk to 10.6 and 10.5. resetting original owner and resolving.

          Show
          Mike Matrigali added a comment - backported fix from trunk to 10.6 and 10.5. resetting original owner and resolving.
          Mike Matrigali made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Assignee Mike Matrigali [ mikem ] C.S. Nirmal J. Fernando [ nirmal ]
          Fix Version/s 10.5.3.2 [ 12315436 ]
          Fix Version/s 10.6.2.3 [ 12315434 ]
          Resolution Fixed [ 1 ]
          Knut Anders Hatlen made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Gavin made changes -
          Workflow jira [ 12508974 ] Default workflow, editable Closed status [ 12801141 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          153d 5h 12m 1 Knut Anders Hatlen 21/Sep/10 17:29
          Closed Closed Reopened Reopened
          133d 2h 31m 2 Kathey Marsden 02/Feb/11 23:39
          Reopened Reopened Resolved Resolved
          13d 21h 41m 2 Mike Matrigali 16/Feb/11 21:20
          Resolved Resolved Closed Closed
          134d 16h 39m 2 Knut Anders Hatlen 30/Jun/11 10:21

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development