06f77ab19c
The AnyTerritory entries in the zoneDataTable are derived from territory="ZZ" entries in the upstream CLDR data; the World ones from territory="001". The latter give the default IANA ID for each MS ID, the former give an (often legacy) IANA ID for the MS ID, that is not based on geography. Some of these are being removed at CLDR v46. The documentation said the ZZ entries have "no known territorial association", hinting that there may be some (unknown) territorial association; however, CLDR's inclusion of them is as entries with a known non-territorial association, so revise the phrasing to reflect this. Also document that windowsIdToDefaultIanaId() returns empty when there is no territory-specific value, and callers can use the territory-neutral call to get a suitable value in that case. (They may, however, wish to distinguish this case, to treat it differently, so I decided not to just return that in place of empty in any case.) The upstream CLDR tables do have entries for territory 001, so we should report these if asked for World as territory. Amend the available zone ID lookup and mapping from MS to IANA functions that take a territory to duly handle World via the default-data that was derived from 001 data in CLDR, instead of from the territory-varying table, from which those were effectively filtered out when generating the two tables. Update docs to mention this handling of World, for contrast with that of AnyTerritory. In the process remove a spurious split-on-space from the MS to default IANA lookup, asserting there is no space (in a field now stored in the table for single IANA ID entries, instead of the one for space-joined lists of them in which it used to be stored, before I noticed it's always only one ID). There is a matching assertion in the cldr.py code that extracts the data. Added an assertion to this last, that each default IANA ID given by CLDR's MS data does in fact also appear as one of the IANA IDs for at least one territory (potentially ZZ), and comment in C++ code on why this means we don't need to scan the windowsDataTable in a few places, where it would just produce duplicate entries. On picking to 6.8, removed the timezone_locale addition, only relevant on 6.9 and later. [ChangeLog][QtCore][QTimeZone] Corrected handling of QLocale::World and clarified in docs how QLocale::AnyTerritory is handled when QTimeZone selects zones by territory. Task-number: QTBUG-130877 Change-Id: I861c777c68b0cb73a194138fe23fbff839df49e6 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit e23dc7c420297fb62db9834a17c59bbf5992dad7) Reviewed-by: Mate Barany <mate.barany@qt.io> |
||
|---|---|---|
| .. | ||
| auto | ||
| baseline | ||
| benchmarks | ||
| global | ||
| libfuzzer | ||
| manual | ||
| shared | ||
| testserver | ||
| CMakeLists.txt | ||
| README | ||
README
This directory contains autotests and benchmarks based on Qt Test. In order
to run the autotests reliably, you need to configure a desktop to match the
test environment that these tests are written for.
Linux X11:
* The user must be logged in to an active desktop; you can't run the
autotests without a valid DISPLAY that allows X11 connections.
* The tests are run against a KDE3 or KDE4 desktop.
* Window manager uses "click to focus", and not "focus follows mouse". Many
tests move the mouse cursor around and expect this to not affect focus
and activation.
* Disable "click to activate", i.e., when a window is opened, the window
manager should automatically activate it (give it input focus) and not
wait for the user to click the window.