Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-67010

ch15/15.9/15.9.5/15.9.5.43/15.9.5.43-0-8 fails when US enters summer time

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P3: Somewhat important
    • Resolution: Done
    • Affects Version/s: 5.11, 5.12
    • Fix Version/s: 5.11.1
    • Labels:
      None
    • Environment:
      Reproducible on Linux, not sure about others. CI only runs those tests on Linux.
    • Commits:
      fb20d2f7b149725b0fcc8e5bbb377cd6dababc9b

      Description

      The ch15/15.9/15.9.5/15.9.5.43/15.9.5.43-0-8 test from the ES5 tests began failing on March 11th when the US time zones enter summer time daylight savings.

      Reduced test-case (can be reduced further of course):

      function runTestCase(testcase) {
          if (testcase() !== true) {
              print("Test case returned non-true value!");
          }
      }
      
      function testcase() {
              var timeZoneMinutes = new Date().getTimezoneOffset() * (-1);
              var date, dateStr;
              try {
                  if (timeZoneMinutes > 0) {
                      date = new Date(1970, 0, -99999999, 0, 0, 0, -1);
                  } else {
                      date = new Date(1970, 0, -99999999, 0, 0 + timeZoneMinutes - 60, 0, -1);
                  }
      
                  dateStr = date.toISOString();
      
                  return false;
              } catch (e) {
                  return e instanceof RangeError;
              }
          }
      runTestCase(testcase);
      

      Run with qmljs test.js and observe how with TZ="America/Vancouver" qmljs test.js it fails (on Linux box configured to CET).

      When "passes" we run into the first if() and the resulting date object is a NaN because the intermediate double value crosses the 8.64e15 threshold in TimeClip, causing the toISOString() call to throw the expected range error.

      When it "fails" we have timeZoneMinutes == -420 and end up with -480 as value for the minutes parameter to the Date constructor. The resulting intermediate double value passed to TimeClip is just below the 8.64e15 threshold and we don't generate a NaN date.

        Attachments

          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            Activity

              People

              Assignee:
              Eddy Edward Welbourne
              Reporter:
              shausman Simon Hausmann
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: