79340518d7
The second pass through each test case, going via UTC, applied an adjustment to the time; however QTime wraps around modulo the day, so applying a negative adjustment to a time too near the start of the day could produce a time at the end of the day. I'm preparing to add some test-case variants for which the transition's UTC date differs from the date in the zone doing it, which trigger this. Combine the time with the date before applying the adjustment, so that the date gets decremented to match the time's wrap-around and conversion from UTC duly gets back to the correct place, not a day later. The new test cases (in an imminent commit) thus pass. Change-Id: I1bd5f191c7673a56ac3fbfc69eab0bc03c9e40b3 Reviewed-by: Mate Barany <mate.barany@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io> |
||
---|---|---|
.. | ||
qcalendar | ||
qdate | ||
qdatetime | ||
qdatetimeparser | ||
qtime | ||
qtimezone | ||
CMakeLists.txt |