4aba97e062
The resolution selects a point in time outside the gap, which will be represented by toMSecsSinceEpoch()'s return, despite the QDT object's isValid() returning false. Previously we retained the originally-calculated msecs, so as to keep date() and time() matching what was asked for. However, this required adjusting offset, which was not remembered for local times within 2^55 milliseconds of the start of 1970. This lead to an inconsistency between the offset from UTC reported for the resolution for a local time further from the epoch, or for a time-zone, and the actual offset from UTC at the time indicated by the return from toMSecsSinceEpoch(). Instead, retain the actually calculated offset (even if we aren't going to remember it) and adjust the msecs to the value that ensures toMSecsSinceEpoch() will get the selected resolution. This incidentally means that, when toMSecsSinceEpoch() has to re-resolve (for a local time within 2^55 msecs of the epoch), it avoids revisiting the complications of hitting the gap. In passing, change internal stateAtMillis() to take the QTimeZone it is passed by const reference, to save a copy (noticed during debug). Also tweak a comment in a test to be explicit about a default value. [ChangeLog][QtCore][Possibly Significant Behavior Change] When QDateTime is instantiated for a combination of date and time that was skipped, by local time or a time-zone, for example during a spring-forward DST transition, the invalid result's time() - and, in rare cases, date() - no longer match what was asked for. Instead, these values and offsetFromUtc() now match the point in time identified by toMSecsSinceEpoch(). Change-Id: Id61c4274b365750f56442a4a598be5c14cfca689 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> |
||
|---|---|---|
| .. | ||
| auto | ||
| baseline | ||
| benchmarks | ||
| global | ||
| libfuzzer | ||
| manual | ||
| shared | ||
| testserver | ||
| CMakeLists.txt | ||
| README | ||
This directory contains autotests and benchmarks based on Qt Test. In order
to run the autotests reliably, you need to configure a desktop to match the
test environment that these tests are written for.
Linux X11:
* The user must be logged in to an active desktop; you can't run the
autotests without a valid DISPLAY that allows X11 connections.
* The tests are run against a KDE3 or KDE4 desktop.
* Window manager uses "click to focus", and not "focus follows mouse". Many
tests move the mouse cursor around and expect this to not affect focus
and activation.
* Disable "click to activate", i.e., when a window is opened, the window
manager should automatically activate it (give it input focus) and not
wait for the user to click the window.