From 81858bf1722081d99fdea72f55e67c04c5bb3d92 Mon Sep 17 00:00:00 2001 From: Edward Welbourne Date: Wed, 4 Nov 2015 10:26:37 +0100 Subject: Don't pretend we know what DST to use for an offset date. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When QDateTime::addDate() and friends sanitize their end-state, they were using the DST status of their start-state (if known) to control it. This lead to misguided results and, in particular, inconsistent results given that a raw-constructed QDateTime comes into being ignorant of its DST, while a .toLocalTime() one knows its DST. Furthermore, the code to do this was triplicated, tricky and poorly explained. So pull it out into a local static function and explain what it's doing, and why, more clearly and only once. Task-number: QTBUG-49008 Change-Id: Ia4bb3c5e9267fff8bb963ea705267998218ed623 Reviewed-by: Jędrzej Nowacki --- tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp | 2 -- 1 file changed, 2 deletions(-) (limited to 'tests/auto') diff --git a/tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp b/tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp index 216c670aee..228ce73c6b 100644 --- a/tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp +++ b/tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp @@ -1616,9 +1616,7 @@ void tst_QDateTime::springForward_data() if (europeanTimeZone) { QTest::newRow("Europe from day before") << QDate(2015, 3, 29) << QTime(2, 30, 0) << 1 << 60; -#if 0 // FIXME: fails QTest::newRow("Europe from day after") << QDate(2015, 3, 29) << QTime(2, 30, 0) << -1 << 120; -#endif // } else if (otherZone) { } else { QSKIP("No spring forward test data for this TZ"); -- cgit v1.2.3