Kludge round MS TZ APIs' lies breaking a test

Commit 68bcccac took account of MS TZ APIs mis-describing non-DST
zones making changes to standard offset (e.g. Europe/Samara in 2011 at
the end of October); however a DST transition that coincides with an
equal and opposite change to standard offset, while the other end of
its DST period changes normally, ends up looking exactly the same
(although it's nominally subtly different), in MS's APIs.  Thus fixing
the more common case broke this more obscure case; there is no way to
fix this (other than not using MS's broken-by-design APIs).  So kludge
the test to skip the bit we know this breaks.

Task-number: QTBUG-64985
Change-Id: I068500e2e783ab72b400bfd6dbb7dbbd5b08a7bc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>

tests/auto/corelib/tools/qtimezone/tst_qtimezone.cpp

@@ -438,6 +438,14 @@ void tst_QTimeZone::transitionEachZone()
     QTimeZone named(zone);
 
     for (int i = start; i < stop; i++) {
+#ifdef Q_OS_WIN
+        // See QTBUG-64985: MS's TZ APIs' misdescription of Europe/Samara leads
+        // to mis-disambiguation of its fall-back here.
+        if (QOperatingSystemVersion::current() <= QOperatingSystemVersion::Windows7
+            && zone == "Europe/Samara" && i == -3) {
+            continue;
+        }
+#endif
         qint64 here = secs + i * 3600;
         QDateTime when = QDateTime::fromMSecsSinceEpoch(here * 1000, named);
         qint64 stamp = when.toMSecsSinceEpoch();