Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.6.0, 5.6, 5.7, 5.8
-
None
-
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
- relates to
-
QTBUG-56923 V4's Date claims to extend toLocale*String() in ways expressly forbidden by ECMA-262
- Open
-
QTBUG-67272 Using QTime in QML should produce a warning
- Closed
- resulted in
-
QTBUG-54559 [iOS] Calendar displays greyed-out days from previous month if navigating to specific date ranges
- Closed
-
QTBUG-67010 ch15/15.9/15.9.5/15.9.5.43/15.9.5.43-0-8 fails when US enters summer time
- Closed