Derby
  1. Derby
  2. DERBY-4107

The Reference Guide incorrectly describes the behavior of the DATE function when applied to an integer argument

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.4.2.0
    • Fix Version/s: 10.6.1.0
    • Component/s: Documentation
    • Labels:
      None
    • Environment:
      MS Windows XP Professional Version 2002 Service Pack 2, running NetBeans IDE 6.5
    • Urgency:
      Normal

      Description

      When Derby Reference Manual, version 10.4, lists Derby limitations for DATE is said that the smallest DATE value is 0001-01-01 and the largest DATE value is 9999-12-31.

      When the same manual explains the DATE function is said that:

      "The argument must be ... a positive number less than or equal to 2,932,897 ... The result is the date that is n-1 days after January 1, 0001, where n is the integral part of the number."

      Testing for the largest integer returns the expected result:

      select date(2932897) from SYSIBM.SYSDUMMY1 returns 9999-12-31 -> OK

      The problem comes when testing the smallest integer. We get a result different than we expect:

      select date(1) from SYSIBM.SYSDUMMY1 returns 1970-01-01, but it should have returned 0001-01-01

      The smallest date we get using integer as an argument to date function should be the same we get when using the smallest string representation as an argument. In other words date(1) should be equal to date('0001-01-01').

      select date('0001-01-01') from SYSIBM.SYSDUMMY1 returns 0001-01-01 -> OK

      1. rrefdatefunc.html
        4 kB
        Bryan Pendleton
      2. docs.diff
        1 kB
        Bryan Pendleton

        Issue Links

          Activity

          Nelson Rodrigues created issue -
          Yun Lee made changes -
          Field Original Value New Value
          Assignee Yun Lee [ yunlee ]
          Hide
          Nelson Rodrigues added a comment -

          This problem may be related to DERBY-4106 issue.

          Show
          Nelson Rodrigues added a comment - This problem may be related to DERBY-4106 issue.
          Dag H. Wanvik made changes -
          Link This issue is related to DERBY-4106 [ DERBY-4106 ]
          Hide
          Rick Hillegas added a comment -

          Triaged July 2: Marked as WrongQueryResult and assigned normal urgency.

          Show
          Rick Hillegas added a comment - Triaged July 2: Marked as WrongQueryResult and assigned normal urgency.
          Rick Hillegas made changes -
          Bug behavior facts [Wrong query result]
          Urgency Normal
          Hide
          Rick Hillegas added a comment -

          I am changing this from a SQL bug to a docs bug. The documentation says that the DATE() function, applied to positive integer arguments, results in days counting up from the first day of the common era. This is not true. The days count up from the beginning of the UNIX epoch, that is, January 1, 1970. I think there is a typo in the documentation.

          Note that the highest integer argument which you can pass to the DATE function is 2932897. That many days after the start of the UNIX epoch is 9999-12-31, I think. At least my back of the envelope calculation, which doesn't account for leap days, comes in around there. If DATE were counting from the beginning of the common era, then DATE( 2932897 ) would be something like 8029-12-31.

          I am also unchecking the "wrong query result" box. I can't find this function in the SQL standard and I don't see any industry consensus about how DATE should behave when applied to integer arguments. I don't see any compelling reason to change Derby's behavior to something different, particularly since that kind of change would create compatibility problems.

          Show
          Rick Hillegas added a comment - I am changing this from a SQL bug to a docs bug. The documentation says that the DATE() function, applied to positive integer arguments, results in days counting up from the first day of the common era. This is not true. The days count up from the beginning of the UNIX epoch, that is, January 1, 1970. I think there is a typo in the documentation. Note that the highest integer argument which you can pass to the DATE function is 2932897. That many days after the start of the UNIX epoch is 9999-12-31, I think. At least my back of the envelope calculation, which doesn't account for leap days, comes in around there. If DATE were counting from the beginning of the common era, then DATE( 2932897 ) would be something like 8029-12-31. I am also unchecking the "wrong query result" box. I can't find this function in the SQL standard and I don't see any industry consensus about how DATE should behave when applied to integer arguments. I don't see any compelling reason to change Derby's behavior to something different, particularly since that kind of change would create compatibility problems.
          Rick Hillegas made changes -
          Bug behavior facts [Wrong query result]
          Component/s Documentation [ 11406 ]
          Component/s SQL [ 11408 ]
          Rick Hillegas made changes -
          Summary DATE function returns wrong result for integer argument The Reference Guide incorrectly describes the behavior of the DATE function when applied to an integer argument
          Bryan Pendleton made changes -
          Assignee Yun Lee [ yunlee ] Bryan Pendleton [ bryanpendleton ]
          Hide
          Bryan Pendleton added a comment -

          I checked and I see that test_DateAndDatetimeFunctionsMore in the DateTimeTest
          in the lang suite has tests for the DATE function which concur with Rick's analysis,
          so I've constructed a patch proposal to the DATE reference page in the manual which
          corrects the description to read 1970, not 0001, for the year.

          I also added an example to the page, to hopefully make it more clear.

          Show
          Bryan Pendleton added a comment - I checked and I see that test_DateAndDatetimeFunctionsMore in the DateTimeTest in the lang suite has tests for the DATE function which concur with Rick's analysis, so I've constructed a patch proposal to the DATE reference page in the manual which corrects the description to read 1970, not 0001, for the year. I also added an example to the page, to hopefully make it more clear.
          Bryan Pendleton made changes -
          Attachment docs.diff [ 12424318 ]
          Attachment rrefdatefunc.html [ 12424319 ]
          Hide
          Bryan Pendleton added a comment -

          Committed the change to the docs trunk as revision 834310.

          Show
          Bryan Pendleton added a comment - Committed the change to the docs trunk as revision 834310.
          Bryan Pendleton made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 10.6.0.0 [ 12313727 ]
          Resolution Fixed [ 1 ]
          Kathey Marsden made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Gavin made changes -
          Workflow jira [ 12457045 ] Default workflow, editable Closed status [ 12801658 ]

            People

            • Assignee:
              Bryan Pendleton
              Reporter:
              Nelson Rodrigues
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development