Derby
  1. Derby
  2. DERBY-4624

Broken logic for avoiding testing across midnight in TimestampArithTest

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.6.1.0
    • Fix Version/s: 10.7.1.1
    • Component/s: Test
    • Labels:
      None

      Description

      TimestampArithTest's decorator has this code to avoid failures in case the test starts close to midnight:

      /*

      • Make sure that we are not so close to midnight that TODAY
      • might be yesterday before we are finished using it.
        */
        while (calendar.get(Calendar.HOUR) == 23
        && calendar.get(Calendar.MINUTE) >= 58)
        Unknown macro: { try { Thread.sleep((60 - calendar.get(Calendar.SECOND)) * 1000); } catch (InterruptedException ie) { // ignore it } }

      There are at least three problems with this code:

      1) (calendar.get(Calendar.HOUR) == 23) never evaluates to true, because calendar.get(Calendar.HOUR) returns values in the range 0-11. Calendar.HOUR_OF_DAY should be used instead.

      2) If the current time is after 23:58 and before 23:59, the code sleeps until 23:59, the test will wait until 23:59 before it starts, making it even more likely that it will cross midnight while running.

      3) The code is executed after the Calendar object has been initialized, so if this code is ever triggered and waits until after midnight, the TODAY field is guaranteed to be yesterday when the test starts executing.

      1. remove_calendar.diff
        3 kB
        Knut Anders Hatlen

        Activity

        Hide
        Knut Anders Hatlen added a comment -

        Committed revision 946079.

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

        The Calendar object is actually only used to initialize some unused fields, so I think removing it along with the dead code is the simplest and best resolution to this issue. The attached patch removes the Calendar object, the broken midnight check that uses the Calendar, and the unused fields ONE_BILLION, TODAY, TOMORROW, YEAR_FROM_TOMORROW, YEAR_FROM_TODAY, YESTERDAY and WEEK_FROM_TODAY, as well as the method isoFormatDate() that's only used to initialize the unused fields.

        Show
        Knut Anders Hatlen added a comment - The Calendar object is actually only used to initialize some unused fields, so I think removing it along with the dead code is the simplest and best resolution to this issue. The attached patch removes the Calendar object, the broken midnight check that uses the Calendar, and the unused fields ONE_BILLION, TODAY, TOMORROW, YEAR_FROM_TOMORROW, YEAR_FROM_TODAY, YESTERDAY and WEEK_FROM_TODAY, as well as the method isoFormatDate() that's only used to initialize the unused fields.
        Hide
        Knut Anders Hatlen added a comment -

        Possibly... But when looking at the test again, I don't really see why this code is needed. We get the Calendar object once and do arithmetic on it, but we never use the current time to verify the values. So I don't see how crossing midnight while running the test will cause any harm.

        Show
        Knut Anders Hatlen added a comment - Possibly... But when looking at the test again, I don't really see why this code is needed. We get the Calendar object once and do arithmetic on it, but we never use the current time to verify the values. So I don't see how crossing midnight while running the test will cause any harm.
        Hide
        Lily Wei added a comment -

        Will it be okay if we kind of guess the range the test will run and just check the time frame in that range? Will that be a valid test to know most of the validation is accurate?

        Show
        Lily Wei added a comment - Will it be okay if we kind of guess the range the test will run and just check the time frame in that range? Will that be a valid test to know most of the validation is accurate?
        Hide
        Knut Anders Hatlen added a comment -

        Good point. I've never seen this test fail because it runs across midnight, so perhaps we should just remove the code rather than trying to fix it?

        Show
        Knut Anders Hatlen added a comment - Good point. I've never seen this test fail because it runs across midnight, so perhaps we should just remove the code rather than trying to fix it?
        Hide
        Dag H. Wanvik added a comment -

        2): wouldn't it just loop forever (since no new time instant is instantiated)?

        Show
        Dag H. Wanvik added a comment - 2): wouldn't it just loop forever (since no new time instant is instantiated)?

          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