Different behaviour in 9.6.04 vs 9.6.08 comparing a time variable with a date constant

Author: jverdugocall@csc.com (jverdugocall)

Hi All, I have detected that the following code behaves differently in 9.6.04 and 9.6.08: variables    time l_t endvariables if (lt >= 1d)    lt = "" endif In the variable l_t I have 21:00 hours being in format CCYYMMDDHHMMSSTT: 0000000021000000. 1d represents the date constant equivalent to 1 day. In 9.6.04 does not enter into the if statement. However in 9.6.08 it enters into the if statement and resets the variable lt. Does anyone know why? Is it a bug? Is it related to the new parameters $NLS_DATE_UNIFACE_PARSER and $NLS_DATETIME_UNIFACE_PARSER added in 9.6.08? Thanks in advance and regards.

5 Comments

  1. Have you tried assigning "1d" to another time variable & checking what's in it in both versions?


    Author: waderg (colpopski@outlook.com)
  2. In both versions when assigning a variable time the value 1d the variable time is 0000000000000000


    Author: jverdugocall (jverdugocall@csc.com)
  3. Try with : variables     datetime l_t endvariables


    Author: LG1949 (l_giuliante@shsistemi.it)
  4. This seems to work:

    variables
     time l_t
    endvariables
    
    if (lt >= $datim(1d))
     lt = ""
    endif

      And the change in behavior was introduced with the version 9.6.05 patch X505. It looks like that this could be a side-effect of the fix for bug 30727 - Rounding problem with date-time arithmetic that is used in a condition. Hope this helps. Kind regards, Daniel Iseli Uniface Technical Support


    Author: diseli (daniel.iseli@uniface.com)
  5. diseli said This seems to work:
    variables
     time l_t
    endvariables
    if (lt >= $datim(1d))
     lt = ""
    endif
      And the change in behavior was introduced with the version 9.6.05 patch X505. It looks like that this could be a side-effect of the fix for bug 30727 - Rounding problem with date-time arithmetic that is used in a condition. Hope this helps. Kind regards, Daniel Iseli Uniface Technical Support  

    Thank you so much for the support.


    Author: jverdugocall (jverdugocall@csc.com)