When matching the long-form L10n-ed name of a time-zone, we currently (since the fix for QTBUG-130278) iterate all available IANA IDs to find one whose long name matches, preferring longer matches over shorter (in case of prefix-matches) but this leaves us with the first IANA ID for a zone with the given name, when several share it, as happens for zones in the same metazone at the given time.

This should be mostly harmless, since all zones in a metazone do agree with each other – but only if the backend we're getting zone offset information from is up to date. Unfortunately, 20 months after Antarctica/Casey kicked its 3-hour DST habit in favour of joining Australia/Perth in Western_Australia, Coin MS VMs haven't updated their registry data to reflect that, but of course CLDR has; since we get offset data from the former and L10n name data from the latter, we end up with Antarctica/Casey as the zone for Western_Australia, but MS gives us the wrong offset data for it.

The remedy is to replace QDTP's findZoneByLongName() helper with a QTimeZone static method that, at least when using the CLDR L10n data, can compare the given text to long names of metazones and return the canonical zone for the metazone it finds, instead of the one whose IANA ID is alphabetically earliest.

For now I shall QEXPECT_FAIL() the afflicted test on MS; and it seems sles-15_sp5-minimal-static needs the same treatment.