Failing fromMSecs/toMSecs round-trip tests on MS-Win

Testing [0] revealed [1] failures in several time-zones on MS-Win, on 1970-10-25 and 2010-10-31; Baghdad failed on the later date, two zones in the Pacific on the former and 22 others on both. On each failing date all times tested failed: round-tripping via QDateTime's fromMsecs/toMSecs got back a changed time_t value. In most cases, the error was exactly the time-zone offset in effect at the time tested; however:

• Pacific/Apia is off by 25 hours in 1970, when its offset was -11 hours (with no DST; it has since switched to +13 with DST);
• Pacific/Fiji is off by 1 hour in 1970, when its offset was +12 hours (with no DST; it has since enabled DST);
• Asia/Thimphu is off by 6 hours in both cases, having shifted from 5.5 to 6 hours in 1987 (so its error matches its present offset, even in 1970 when its offset was different)
• (India/Mahe and India/Reunion are off by 4 hours and I don't know their actual offsets (they have no transitions in the interval); but India/Mauritius is also off by 4 hours and that was its offset at both dates.)

• [0] https://codereview.qt-project.org/162414
• [1] http://testresults.qt.io/logs/qt/qtbase/234cb156aaefeabfd063f3cae47a7d129aae306b/WindowsWindows_7x86WindowsWindows_7x86MSVC2010qtci-windows-7-x86-5c95a9Release_DeveloperBuild_QtNamespace_QtLibInfix_OpenGLDynamic/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/testrun_1475593053/testlog.txt.gz

Full list of zones:

• Africa/Tripoli
• America/Argentina/La_Rioja
• America/Argentina/Rio_Gallegos
• America/Argentina/Salta
• America/Argentina/San_Juan
• America/Argentina/San_Luis
• America/Argentina/Tucuman
• America/Argentina/Ushuaia
• America/Bahia
• America/Buenos_Aires
• America/Catamarca
• America/Cordoba
• America/Jujuy
• America/Mendoza
• Antarctica/Casey
• Asia/Baghdad (only 2010)
• Asia/Dhaka
• Asia/Karachi
• Asia/Thimphu
• Australia/Perth
• Indian/Mahe
• Indian/Mauritius
• Indian/Reunion
• Pacific/Apia (only 1970)
• Pacific/Fiji (only 1970)

Of these only the last two are presently inflicting DST on themselves, although most have flirted with it. None of these zones had a transition in 1970. A few had transitions in 2010, but the one closest to the tested date was Pacific/Apia entering DST a week before.

It is possible we have two bugs here, something like:

• using present zone info for historical dates, at least for some zones; and
• ignoring the zone's offset in one direction of the round-trip while correctly accounting for it in the other, albeit apparently only for some zones.

MS's native APIs may be the culprits: ISTR they make some simplifications, I shall need to read up on them again.