Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8090098

[WebView] getTimezoneOffset() of a ISO strings returns a wrong value

    Details

    • Subcomponent:
      web

      Backports

        Description

        Since java 8u60 we have the problem that the wrong date will be shown Kendo UI components like the datepicker.

        We think that the following bugs are related with the problem that getTimezoneOffset() of an ISO string returns a wrong value.

        new Date('2015-06-09T22:00:00.000Z').getTimezoneOffset()
        should return -120 in case of the following timezone
             (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
        but it returns 1320

        I also noticed that for the following time zones:
        (UTC+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague
        (UTC+01:00) Brussels, Copenhagen, Madrid, Paris
        (UTC+01:00) Sarajevo, Skopje, Warsaw, Zagreb


        In addition we wrote a short page which gives you the possibilty to reproduce that error.

        Open the following page to reproduce the following two bugs
        http://output.jsbin.com/gokoxo

        Bug 1 - Datepicker shows the wrong date
        1. click on the calendar button and select a date like the 6/10/2015
        2. now you should see that the textfield stores the wrong date 6/09/2015

        Bug 2 - Datepicker shows the the same day number for nearly the whole month. (see https://drive.google.com/file/d/0B7P_rknS1TWxSExTTHNPXzBGYVE/view?usp=sharing)
        1. do the same (step 1 and 2) as for bug 1
        2. change the month to september


        These are major bugs for us and we have to told our customers that they should avoid Java 8u60 if these bugs still exist in the release version.

        Thanks in advance!
        Best Regards,
        Steve

          Activity

          Hide
          ant Anton Tarasov added a comment - - edited
          On the alias Steve Hruda suggested applying the only diff:

          diff -r f11aa4f2d7bd modules/web/src/main/native/Source/WTF/wtf/DateMath.cpp
          --- a/modules/web/src/main/native/Source/WTF/wtf/DateMath.cpp Thu Jun 04 11:31:24 2015 +0300
          +++ b/modules/web/src/main/native/Source/WTF/wtf/DateMath.cpp Fri Jul 10 20:01:12 2015 +0200
          @@ -443,6 +443,9 @@

               double diff = ((localSystemTime.wHour - offsetHour) * secondsPerHour) + ((localSystemTime.wMinute - offsetMinute) * 60);

          + if (diff < 0)
          + diff += secondsPerDay;
          +
               return diff * msPerSecond;
           #else
               //input is UTC so we have to shift back to local time to determine DST thus the + getUTCOffset()

          I tested that, at first, it fixes the bug inquestion on Windows, and at second, that it doesn't introduce regressions with the test cases from:

          LayoutTests/fast/forms/date
          LayoutTests/fast/forms/datetime
          LayoutTests/fast/forms/datetimelocal
          LayoutTests/fast/forms/time
          LayoutTests/fast/forms/month
          LayoutTests/fast/forms/week

          (Not all the test cases pass, but the ones which fail, do that identically with and without the fix)

          So, from my side I have nothing against this fix.

          By the way, the patch was suggested by Steve at webkit.org and iit's being processed:

          https://bugs.webkit.org/show_bug.cgi?id=137003
          Show
          ant Anton Tarasov added a comment - - edited On the alias Steve Hruda suggested applying the only diff: diff -r f11aa4f2d7bd modules/web/src/main/native/Source/WTF/wtf/DateMath.cpp --- a/modules/web/src/main/native/Source/WTF/wtf/DateMath.cpp Thu Jun 04 11:31:24 2015 +0300 +++ b/modules/web/src/main/native/Source/WTF/wtf/DateMath.cpp Fri Jul 10 20:01:12 2015 +0200 @@ -443,6 +443,9 @@      double diff = ((localSystemTime.wHour - offsetHour) * secondsPerHour) + ((localSystemTime.wMinute - offsetMinute) * 60); + if (diff < 0) + diff += secondsPerDay; +      return diff * msPerSecond;  #else      //input is UTC so we have to shift back to local time to determine DST thus the + getUTCOffset() I tested that, at first, it fixes the bug inquestion on Windows, and at second, that it doesn't introduce regressions with the test cases from: LayoutTests/fast/forms/date LayoutTests/fast/forms/datetime LayoutTests/fast/forms/datetimelocal LayoutTests/fast/forms/time LayoutTests/fast/forms/month LayoutTests/fast/forms/week (Not all the test cases pass, but the ones which fail, do that identically with and without the fix) So, from my side I have nothing against this fix. By the way, the patch was suggested by Steve at webkit.org and iit's being processed: https://bugs.webkit.org/show_bug.cgi?id=137003
          Hide
          ant Anton Tarasov added a comment -
          webrev: http://cr.openjdk.java.net/~ant/JDK-8090098/webrev.1

          The latest version of the fix, suggested by Steve.

          I only added #if PLATFORM(JAVA) macro and the link to the bug report on webkit.org, in order to have the change marked for the following merge cycle (in case it won't be in the WebKit codebase yet).

          It fixes the reported DST issues on Windows and doesn't cause regressions with the date related DRT tests, at least.
          Show
          ant Anton Tarasov added a comment - webrev: http://cr.openjdk.java.net/~ant/JDK-8090098/webrev.1 The latest version of the fix, suggested by Steve. I only added #if PLATFORM(JAVA) macro and the link to the bug report on webkit.org, in order to have the change marked for the following merge cycle (in case it won't be in the WebKit codebase yet). It fixes the reported DST issues on Windows and doesn't cause regressions with the date related DRT tests, at least.
          Hide
          kcr Kevin Rushforth added a comment -
          +1
          Show
          kcr Kevin Rushforth added a comment - +1
          Hide
          kcr Kevin Rushforth added a comment -
          OK to backport to 8u-dev for 8u66, in order to keep WebKit in sync.
          Show
          kcr Kevin Rushforth added a comment - OK to backport to 8u-dev for 8u66, in order to keep WebKit in sync.
          Show
          ant Anton Tarasov added a comment - changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/90d9e5593f69

            People

            • Assignee:
              ant Anton Tarasov
              Reporter:
              duke J. Duke (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported: