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

V4's Date constructor fails to take account of variations in time-zone offset

    XMLWordPrintable

    Details

    • Commits:
      948e24cb6deeaf0e55794032b90fdf20b7ef12c1, 2b8b7a162be52f8cd6c2bc39f498a1ddfb59dd68

      Description

      qtdeclarative/src/qml/jsruntime/qv4dateobject.cpp's DateCtor::construct() can, if given a date (with no time), manage to return a date-time object late in the previous day: see QTBUG-54559.
      This is unequivocally wrong.

      When time is unspecified, the returned object should represent some time on the correct date; if we can reliably hit 00:00 on that date then we should do so; and we probably can do this, but we have to pay attention.

      The present implementation assumes a fixed time-zone offset: DatePrototype::init() sets LocalTZA once and for all to the current time-zone offset, which is entirely inappropriate for use by functions UTC() and LocalTime() as the adjustment to apply at arbitrary times in the past or future. Time zones do, in fact change.

      We need to make this code actually use QDateTime (which gets most of this sort of thing right) instead of hand-rolling its own crude approximations to something close to right.

        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:
              Eddy Edward Welbourne
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Gerrit Reviews

                  There are no open Gerrit changes