Ran the script, no new IDs to add. Revised tests of Central Standard
Time: America/Ojinaga has joined Matamoros for it, in Mexico.
Pick-to: 6.6 6.5
Fixes: QTBUG-115732
Task-number: QTBUG-111550
Change-Id: I9b41d8c0156b9fbe3961dbe9a35d55493fc55501
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Add the boilerplate standalone test prelude to each test, so that they
can be opened with an IDE without the qt-cmake-standalone-test script,
but directly with qt-cmake or cmake.
Boilerplate was added using the following scripts:
https://git.qt.io/alcroito/cmake_refactor
Manual adjustments were made where the code was inserted in the wrong
location.
Task-number: QTBUG-93020
Change-Id: I28b6d3815c5f43d2c33ea65764f6f3f8f129eaf3
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A zone without transitions, such as any UTC-based one, would
previously return invalid data for the offset data at a given
time. The method was documented to be "the equivalent of calling
offsetFromUtc(), abbreviation(), etc" but these methods do return
sensible data for a zone with no transitions. Furthermore, the backend
data() method on which it depends is implemented by all backends,
including the UTC one, with no transitions.
Fix offsetData() to also return data when no transitions are
available. Improve docs.
Adapt the checkOffset() test to test offsetData() as well as the
various functions to get parts of it. In the process, change that test
to use a QTimeZone row instead of its name as a QByteArray, so that we
can also have rows for lightweight time representations.
Change-Id: I241ecf02a26a228cca972bca5e2db687fe41feb4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Use static constexpr int values instead of abusing enum.
[ChangeLog][QtCore][QTimeZone] The MinUtcOffsetSecs and
MaxUtcOffsetSecs constants are now static constexpr members of
QTimeZone, rather than members of an anonymous enum. Their values are
now 16 hours either side of zero, to allow for some historical zones.
Change-Id: I1c3a0f85a2b83b5010f021ca0f5ca5baefbf32e4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
It turns out that Alaska and The Philippines had historical offsets
exceeding 15 hours, prior to day-transitions to bring their dates in
sync with their respective sides of the international date line.
Change-Id: I48fdf3aa6d8c0bacb368d08316733a10ee11a281
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This saves (mostly in corelib/time/) some complications that used to
arise from needing different code-paths for different time-specs.
Task-number: QTBUG-108199
Change-Id: I5dbd09859fce7599f1ba761f8a0bfc4633d0bef9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore][QTimeZone] QTimeZone is now always defined;
feature timezone now controls most of its prior API and some new API
is added, most of it always present, to enable QTimeZone to package a
Qt::TimeSpec and, for Qt::OffsetFromUTC, its offset. Prior to this
change, APIs using Qt::TimeSpec had to provide a separate function
taking a QTimeZone alongside a function taking a Qt::TimeSpec and
optional offset; it will now be possible to unify these into a single
function taking a QTimeZone. Adaptation of other Qt classes to do so
shall follow.
Task-number: QTBUG-108199
Change-Id: If5ec3cc63920af882ebb333bf69cde266b1f6ad7
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
As a result, also make sure the test will fail if output to debug
stream doesn't produce the expected result.
Change-Id: I9914c9c41c8d8b79f32dfb8e0c735f12e2d59f5e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is a semantic patch using ClangTidyTransformator as in
qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8, but extended to
handle typedefs and accesses through pointers, too:
const std::string o = "object";
auto hasTypeIgnoringPointer = [](auto type) { return anyOf(hasType(type), hasType(pointsTo(type))); };
auto derivedFromAnyOfClasses = [&](ArrayRef<StringRef> classes) {
auto exprOfDeclaredType = [&](auto decl) {
return expr(hasTypeIgnoringPointer(hasUnqualifiedDesugaredType(recordType(hasDeclaration(decl))))).bind(o);
};
return exprOfDeclaredType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))));
};
auto renameMethod = [&] (ArrayRef<StringRef> classes,
StringRef from, StringRef to) {
return makeRule(cxxMemberCallExpr(on(derivedFromAnyOfClasses(classes)),
callee(cxxMethodDecl(hasName(from), parameterCountIs(0)))),
changeTo(cat(access(o, cat(to)), "()")),
cat("use '", to, "' instead of '", from, "'"));
};
renameMethod(<classes>, "count", "size");
renameMethod(<classes>, "length", "size");
except that the on() matcher has been replaced by one that doesn't
ignoreParens().
a.k.a qt-port-to-std-compatible-api V5 with config Scope: 'Container'.
Added two NOLINTNEXTLINEs in tst_qbitarray and tst_qcontiguouscache,
to avoid porting calls that explicitly test count().
Change-Id: Icfb8808c2ff4a30187e9935a51cad26987451c22
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Its debug member can be set where it's declared, making the
constructor redundant.
Change-Id: Ic1195108766a6a86c3392a5bcf7f197ea31e8068
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
A time_zone represents a timezone identified by its IANA ID. This
allows for a straightforward conversion to QTimeZone.
[ChangeLog][QtCore][QTimeZone] QTimeZone can now be constructed
from a std::chrono::time_zone pointer.
Change-Id: I093d9fc2e989475d30730a9dcdef491903a2aeb2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Before the patch we tried to create a java Locale object by passing the
human-readable language, territory and variant strings. However, the
Locale constructor accepts ISO-defined codes.
Fix it by using a factory method Locale.forLanguageTag() [0] that
constructs a Java Locale object based on BCP 47 tag.
[0]: https://developer.android.com/reference/java/util/Locale#forLanguageTag(java.lang.String)
Fixes: QTBUG-101460
Pick-to: 6.3 6.2 5.15
Change-Id: If414c66cf0e5b7e8299ffc3a6038b6f9eb79d5ec
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The zone name was reported if isValid() failed, but not if
isTimeZoneIdAvailable(), where it also proved useful in uncovering
ICU's use of over-long zone name components.
Change-Id: I4b3b65b1a4a338b638c01fc7ad47294118ee0efc
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The exception was previously limited to Android, but I now find that
ICU has the same over-long names; it seems likely that's where Android
gets them. Also update the link to the theory page from the TZ DB, as
it now has an official home on www.iana.org.
Task-number: QTBUG-99747
Pick-to: 6.3 6.2
Change-Id: I9af67426d15609dfaf5f335405ceb1218fcf40ff
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It can now use startOfDay()/endOfDay() for the end-points of its
search range; and it should check transit is not empty before
dereferencing transits.at(0).
Change-Id: Ib1568f4d8d6ce301d601071bb58185be906c631a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The loop used an int counter that was initialized from a size_t,
provoking a warning from MSVC. Since the indexing is irrelevant in any
case, use a ranged-for loop. Since the loop was formerly in decreasing
index order, reverse the table being iterated so that entries remain
in their prior order.
Change-Id: I79b93c5a3f39a502b0cae83215b8e3665d0e17f5
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The offset fields for tst_QTimeZone::specificTransition() had a
comment claiming they are in minutes; they are in fact in seconds, so
fix that. At the same time, Moscow hasn't had a time-zone change since
2017, so the end-date for one of the test intervals can be nudged a
little closer to the present without harm.
Change-Id: I66822cb758f7e00d6added801466a6745be3e31a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Tests of QTimeZone::dispayName() were burying most of what was
interesting in the variations among them by repetition of a large
amount of boilerplate. Package the repetition in a macro so that
the differences between checks are more evident.
Change-Id: I23bcafab641b7d3bed50248ba5313250c150d30c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use the Q_INT64_C() macro and qint64()-as-function instead of C-style
casts.
Change-Id: I9d169715da96a49898e9c9e2a6d3ee5182e1d91c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Where std::numeric_limits<...>::min() is used used as invalid value
for an API return, save it as a named constant so that the comparisons
are against an informative name, rather than leaving the reader to
guess the significance of the min-value.
Change-Id: Ia99c75e21856f65cb4494120d05eed36f5fc2d50
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It is no longer handled separately from Android.
This effectively reverts commit 6d50f746fe
Change-Id: Ic2d75b8c5a09895810913311ab2fe3355d4d2983
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
QDateTime has long followed a convention of ignoring what it knows
about time-zone transitions before the epoch. This produces unhelpful
artefacts (such as an ahistorical spring-forward skipping the first
hour of 1970 in Europe/London, which was in permanent DST at the time)
and complicates the code. It documented that DST transitions were
ignored, but in fact ignored all transitions prior to 1970 and simply
assumed that the current time-zone properties (half a century later)
applied to all times before 1970.
This appears to be based on the fact that the MS APIs using time_t all
limit their range to after 1970. Given that we have to resort to
"other means" to deal with times after the end of time_t, when it's
only 32-bit (and after year 3000, on MS systems), we have the means in
place to handle times outside the range supported by the system APIs,
so have no need to mimic this restriction. (Those means are not as
robust as we might want, but they are less bad than assuming that the
present zone properites were always in effect prior to 1970.) On
macOS, the time_t functions only reach back to the start of 1900; it
reaches to the end of its time_t range and Linux covers the whole
range. Given this variety, the range is now auto-detected the first
time it is needed (based on some quick and dirty heuristics).
Various CET-specific tests now need adjustments in tests of times
before the introduction of time-zones (when they are in fact on LMT,
not CET). The systemZone() test of QTimeZone can now restore its
pre-zone test cases. Various comments on tests needed updates.
[ChangeLog][QtCore][QDateTime] Available time-zone information is now
used to its full extent, where previously QDateTime used LocalTime's
current standard time for all dates before 1970. Where we have
time-zone information, it is considered reliable, so we use it. This
changes the "best efforts" used for times outside the range supported
by the system APIs, in most cases giving less misleading results.
Fixes: QTBUG-80421
Change-Id: I7b1df7622dd9be244b0238ed9c08845fb5b32215
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This reverts commit ec8808c302 but
retains its test, as the problem it fixed is now solved by having the
TZ backend validate the ID it's passed, so that it now only accepts
valid POSIX zone-descriptions and valid IANA IDs. The former were
being excluded by this check.
Amended a POSIX test to fail with the check in place; it passes now.
Change-Id: I0d5e8c6e0a315ac2509f3d23bebb52aede8f79d0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Previously, an apparent POSIX rule would be saved and any defects in
it would only be discovered when trying to use it to generate
transitions. Instead, check that it has the right form during the
initial parsing of its data.
In the process, since checking for DST in the process is trivial,
implement a long-standing TODO to cache hasDaylightTime()'s
answer. The array it scanned was in any case being scanned during
construction, so detecting DST in init()'s scan is trivial; and its
failure to check the POSIX rule mean it failed to notice when zones
entirely specified by a POSIX rule have DST.
Adapt a test using a POSIX-only rule to verify it does know the zone
has DST; it did not, before this change.
Change-Id: I690c013d3331600f7348dae61c35d41e5599da70
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The description necessarily has fake transitions at start and end of
the year, potentially outside the year. These transitions should not
be reported by QTzTimeZonePrivate as transitions, although its data()
must find a "transition" whose data it can use (as in the permanent
standard time case, which could potentially be represented the same
way, although there's a saner way to do so, that the code already
handles) to report the zone's properties.
In the process, fix (and make more straightforward) the convoluted
decision-making code that was deciding which transitions to include in
the returned list. It was assuming invalidMSecs() would be set as the
atMSecsSinceEpoch of a transition, although this is computed in a way
that makes that value most unlikely, even when the result is invalid.
It also rather confusingly mixed < 0 tests as tests for overflow with
the one < 0 test that's about ignoring DST before 1970. Also added
comments to clarify some of what's going on there.
Expanded a recently-added test of a permanent DST zone to verify this
now works correctly.
Change-Id: Ia8d98f433fb1e479dba5479220a62196c30f0244
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There are two formats for such fields: one with a J prefix on a number
in the range 1 to 365, the other with no prefix and a range from 0 to
365. The code mistakenly treated the latter as if its range were from
1 to 366. The J-form doesn't count Feb 29th, so March always starts on
day 60; the code tried to take that into account, but adjusted in the
wrong direction (and this mislead me, in a recent partial fix, into a
fence-post error).
Add a test-case based on the Africa/Casablanca POSIX rule seen on RHEL
8.2, which tripped over the off-by-one error without a J prefix. This
incidentally also tests the J case.
Change-Id: I692ca511e5c960f91a6c21073d3b2f037f5e445f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A POSIX rule's transition time is allowed an hour in the range from
-137 to 137; in particular, a negative hour is allowed, and used by
some Greenland zones using Europe's time-of-transition which, as they
are more than two hours west of Greenwich, happens before midnight.
This means the time of transition can't be represented by a QTime(),
so propagate the int that represents it to the code that consumes it;
and treat parsing failure as an error rather than "correcting" it - if
the transition time is given, it must be valid.
Changed tst_QTimeZone::isTimeZoneIdAvailable()'s verification of
validity to report the name of the zone it thought was invalid.
(A later change, validating POSIX rules, caued this to fail for
America/Nuuk without the present fix.)
Change-Id: I5c9127ac34d878554dd0aca1c1c7338c7e0e1c28
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If the ID isn't even valid, don't waste cycles trying to make sense of
it as identifying a time-zone.
Add test of an invalid ID that provoked an integer overflow on trying
to parse it as a POSIX zone specification.
Fixes: QTBUG-92842
Change-Id: Ib80bbb88c11c0484ce0358acabbdc25c5bd8e0b3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If the backends run into an error in computing the offset, they return
INT_MIN; but they are valled via the front-end, which returns zero
when the zone is invalid. So treat INT_MIN returns from the backend
the same as the case of being invalid.
Change-Id: Ic3c4dfe964dbfba4030c770213eca8a63e84736d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The use of "Country" is misleading as some entries in the enumeration
are not countries (eg, HongKong), for all that most are. The Unicode
Consortium's Common Locale Data Repository (CLDR, from which QLocale's
data is taken) calls these territories, so introduce territory-based
names and prepare to deprecate the country-based ones in due course.
[ChangeLog][QtCore][QLocale] QLocale now has Territory as an alias for
its Country enumeration, and associated territory-based names to match
its country-named methods, to better match the usage in relevant
standards. The country-based names shall in due course be deprecated
in favor of the territory-based names.
Fixes: QTBUG-91686
Change-Id: Ia1ae1ad7323867016186fb775c9600cd5113aa42
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The POSIX rule parser used by QTzTimeZonePrivate recklessly assumed
that, if splitting the rule on a dot produced more than one part, it
necessarily produced at least three. That's true for well-formed POSIX
rules, but we should catch the case of malformed rules.
Likewise, when calculating the dates of transitions, splitting the
date rule on dots might produce too few fragments; and the fragments
might not parse as valid numbers, or might be out of range for their
respective fields in a date. Check all these cases, too.
Added a test that crashed previously. Changed
QTimeZone::offsetFromUtc() so that its "return zero on invalid"
applies also to the case where the backend returns invalid, in
support of this.
Fixes: QTBUG-92808
Pick-to: 6.1 6.1.0 6.0 5.15
Change-Id: Ica383a7a987465483341bdef8dcfd42edb6b43d6
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Test we get the same starts of various days. Some coming changes shall
break some of these, but they should all be back to working by the
time we're taking account of DST before 1970 as well as after.
The first two or three test-cases work by accident in most zones, at
present, due to the zone-based code-path ignoring the LMT period
before the zone's first transition; but Europe/Helsinki had a renaming
transition in 1878, so does see its pre-zone offset between then and
the switch to UTC+2 in 1921, leading to failures in exactly the zone
Coin tests. So suppress these three test-cases pending later fixes.
On Windows, the next text (still pre-epoch) gets bogus zone data for
its LocalTime, so suppress that likewise.
Task-number: QTBUG-80421
Change-Id: I2264e0e436d92112b03264faa410e30057b8f73b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
In QTimeZonePrivate::dataForLocalTime(), mistrust the Android
backend's hasDaylightTime(), as it has a comment saying it only knows
about future transitions, not past. This caller of it really needs to
query "has ever had a transition", which this doesn't answer. Many
zones that have no plans for future transitions have had transitions
in the past; these were failing the transitionEachZone() test.
In the process, refine the test itself, making sure we catch some
quirk cases that shouldn't arise and making the debug message on
failure more informative (while eliding the zone name, as this is part
of the test name anyway, so added to the output by qDebug() itself).
Fixes: QTBUG-69131
Change-Id: I88a0528182c247acb8b6327b40516178e455bcc0
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The QTimeZone tests have some helper functions to test details of a
QTZP instance; these use QCOMPARE(), so may return early on failure.
The callers then need to notice the failure and, in their turn, also
return.
Change-Id: I0a188e9641ced70c9ffedd95e91f39681fad768a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Its back-end lacks transition data, so the test can't possibly
succeed. Make the skip conditional on the tested zone having
transitions, so that the test will come back into play if we ever gain
support for transitions on Android.
Fixes: QTBUG-69129
Change-Id: Ie4f96601b8b18cd496efbde7cf2557875cf3c1c9
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Dating from the origins of our support for the zoneinfo file format,
the mapping of POSIX's day-numbering (0 = Sunday through 6 = Saturday,
see [*]) to Qt's (1 = Monday through 7 = Sunday) was done by mapping 0
to 1, when it should have been 7.
[*] http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
Corrected a QTimeZone test that trusted the results it got without
checking which day of the week those were: they were all Mondays.
Verified that the corrected dates are in fact Sundays.
Checked the zone abbreviations, too.
Fixes: QTBUG-90553
Pick-to: 6.0 5.15
Change-Id: I84b4b14f9892ff687918cd3c42c7c9807e45313c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
It used QString.compare() and assumed it was returning a bool true on
equality, when it actually returns an int that compares to 0 as the
given strings compare. So it should use compare() == 0.
This fixes several of QTimeZone's blacklisted tests on Android and a
crasher, which we dodged with a QSKIP. Added an id-comparison to a
test. Gave two local variables more informative names, made an early
return into a QSKIP so it explains itself.
Fixes: QTBUG-89905
Fixes: QTBUG-69122
Fixes: QTBUG-69132
Fixes: QTBUG-87435
Pick-to: 6.0 5.15
Change-Id: Icf18ed5a810143d6e65d36e34a70e82faac10b8e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
When creating a time-zone from a UTC+offset name that isn't known to
the system, QTimeZone (since the fix to QTBUG-77738 in 5.15.0) falls
back to constructing a suitable UTC-offset backend; however, the id of
this is not guaranteed to match the id passed in to the constructor.
In all other cases, the id of a QTimeZone does match the id passed to
its constructor.
Some utcOffsetId testcases had different id() than the id passed to
the constructor, due to mismatches where a zone was constructed using
the fall-back but the generated id included its minutes (as :00) or
omitted its seconds. The omission of seconds is clearly a bug, but we
also don't want to include :00 for seconds when it's not needed. So
change QTimeZonePrivate::isoOffsetFormat() to accept a
QTimeZone::NameType to configure how much we include in an id. Its
callers other than the relevant constructor (from offset) still get
minutes, even when :00, but will also get seconds added if that isn't
zero; and the constructor from offset now gets the short form obtained
by omitting all trailing zeros.
Since all valid whole-hour offset names that do include :00 for the
minutes field are in fact known standard offset names, the elision of
minutes will only affect zones created by ID in the case of a
whole-hour offset given without :00 minutes specifier, so these shall
necessarily in fact get the ID passed to the constructor. Creating by
UTC-offset with a name that specifies zero seconds will result in a
QTimeZone instance whose id() differs from what was passed to its
constructor (eliding the :00 seconds and potentially also minutes, if
also zero) but this should be the only case where a QTimeZone's id
doesn't match the one passed to the constructor, when constructed by
id.
Fixed inconsistency between the offset-constructor's declaration
(taking offset as int) and definition (taking qint32) in the process.
Added an id check to the utcOffsetId() testcase. Amended two tests of
offset-derived time-zones' IDs, added comments to make clear how one
of those differs from a matching standard name test and converted two
uses of QCOMPARE(, true) to QVERIFY().
[ChangeLog][QtCore][QTimeZone] QTimeZone instances created by offset
from UTC (in seconds) shall now only include minutes in their ID when
the offset is not a whole number of hours. They shall also include the
seconds in their ID when the offset is not a whole number of minutes.
Pick-to: 6.0 5.15
Task-number: QTBUG-87435
Change-Id: I610e0a78e2aca51e12bfe003497434a998e93dc7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remove the qmake project files for most of Qt.
Leave the qmake project files for examples, because we still test those
in the CI to ensure qmake does not regress.
Also leave the qmake project files for utils and other minor parts that
lack CMake project files.
Task-number: QTBUG-88742
Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Complete search and replace of QtTest and QtTest/QtTest with QTest, as
QtTest includes the whole module. Replace all such instances with
correct header includes. See Jira task for more discussion.
Fixes: QTBUG-88831
Change-Id: I981cfae18a1cabcabcabee376016b086d9d01f44
Pick-to: 6.0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We want to re-enable Android tests in QTQAINFRA-3867. However,
many tests are failing already preventing that from happening.
QTBUG-87025 is currently keeping track (links) to all of those
failing tests.
The current proposal is to hide those failing tests, and enable
Android test running in COIN for other tests. After, that try
to fix them one by one, and at the same time we can make sure
no more failing tests go unnoticed.
Task-number: QTBUG-87025
Change-Id: Ic1fe9fdd167cbcfd99efce9a09c69c344a36bbe4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
