From 0cad974d0da72e96944108df2face676f5ec250d Mon Sep 17 00:00:00 2001 From: Edward Welbourne Date: Wed, 24 Nov 2021 17:34:37 +0100 Subject: [PATCH] Add a note to save the next reader some confusion I was briefly confused about why an Etc/GMT+3 test was using GMT as localtime. Fortunately I worked it out before mis-"correcting" it. Change-Id: I7b0473c7d3974ef186e1170cf4999aca52aaaf45 Reviewed-by: Andreas Buhr --- tests/auto/corelib/time/qdatetime/tst_qdatetime.cpp | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tests/auto/corelib/time/qdatetime/tst_qdatetime.cpp b/tests/auto/corelib/time/qdatetime/tst_qdatetime.cpp index b8f61ea8fd..1b12abdcf9 100644 --- a/tests/auto/corelib/time/qdatetime/tst_qdatetime.cpp +++ b/tests/auto/corelib/time/qdatetime/tst_qdatetime.cpp @@ -2905,6 +2905,10 @@ void tst_QDateTime::fromStringStringFormat_localTimeZone_data() bool lacksRows = true; #if QT_CONFIG(timezone) + // Note that the localTimeZone needn't match the zone used in the string and + // expected date-time; indeed, having them different is probably best. + // Both zones need to be valid; GMT always is, so is a safe one to use for + // whichever the test-case doesn't care about (if that applies to either). QTimeZone etcGmtWithOffset("Etc/GMT+3"); if (etcGmtWithOffset.isValid()) { lacksRows = false;