This fixes the documentation side of an issue with QTZ::displayName()
not doing what's documented. (The MS-eccentricities have been fixed by
earlier work.)
Fixes: QTBUG-84297
Change-Id: I3ec522aa81741fbf2d3dd247786310304e14f304
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit b3a00a38af1226ebd6617638872d540f1ecd76df)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Raised in 6.8 API change review. The use of "matches" in a name suggests
pattern-matching, which isn't what happens here.
Task-number: QTBUG-125859
Change-Id: I8aa05b117807b9d1b9b737cd63d44fb4a30f6fa5
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 6b36e5de7656e1d9e23364c596cc82f8068d4452)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This makes it possible for the stdCompatibility() test to cope with
the backend (based on the Windows Registry, which disagrees with MS's
ICU-based std::chrono::tzdb) successfully constructing a zone, by
finding a known alias, instead of failing because it doesn't know the
name. It may also be useful to client code when dealing with legacy
names.
Amended some existing tests to only expect what they now should and
added some tests specific to aliasMatches(). Also added some
explanative comments where it isn't needed.
Task-number: QTBUG-115158
Change-Id: I095bdbead78df339e29b29518d5010ef905fa8b2
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
There are various legacy IANA IDs that we should recognize as aliases
for their contemporary equivalents. Later work shall also take these
into account in the Windows IDs. Scan CLDR's data about these aliases
and use it when constructing QTimeZone. This adds aliasMappingTable
and aliasIdData arrays to QTZP_data_p.h and an AliasData type to its
QtTimeZoneCldr namespace.
Change-Id: I1bbfce62959a7e1b7a0bc4a320c32f5a174a2ff2
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The ICU backend was using its base's displayName() but none of the
other backends did so; have them do the same. This saves the need for
a QTZP:: suffix one one call to the UTC backend's displayName().
The order of backends in the header is a jumbled mess and the set of
could surely be reduced to a #if...#elif...#endif chain, especially
once TZ's dependence on ICU is sorted out, so add a TODO about that.
Change-Id: I6d6daf3f899f7c79538a7d16bc94b0610f1a4c28
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Follow up to commit 00d9a9a9b59650b8e297f91dcc600c377da5bceb - as
commented in the QTZ constructor, one of the reasons for the prior "is
available" check was to avoid creating TZ cache entries for it; so
have the TZ backend also (like ICU) overtly check for availability
before trying to find data for the given ID. This duplicates work done
later in the constructor, which can perhaps be optimised out later,
but is no worse than where we were before the commit mentioned above.
Pick-to: 6.7 6.6 6.5
Task-number: QTBUG-121807
Change-Id: Ie0571df2de2bf0a3f4ee767184e58b378e8cb05a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... to describe the comparison operators provided by these classes.
Do not remove the existing documentation of individual operators for
now, because the new commands do not contain any links to explain what
do the types of ordering actually mean.
Task-number: QTBUG-119433
Pick-to: 6.7
Change-Id: I663b992377ea8b00ffa0c0a64da0733e3772d1dd
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
ICU returns a "valid" representation of GMT when given an unrecognised
ID, so QTZ's constructor has been checking the ID is available before
passing it to the backend constructor. That availability check was
done by generating the list of available IDs to see if the given ID
was in it; this is very inefficient. Furthermore, the QTZ constructor
was also checking availability, to work round the same issue in only
this one backend, making the check redundant.
So overide isTimeZoneIdAvailable() in the ICU backend, calling
ucal_getCanonicalTimeZoneID(), which answers the question directly;
and drop the duplicate check in the QTZ constructor. Expand a test to
verify an invalid name is rejected.
Fixes: QTBUG-121807
Pick-to: 6.7 6.6 6.5
Change-Id: I34f996b607b958d12607a94eb273bb1b406cca1a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
isTimeZoneIdAvailable() is significantly slower than just trying to
initialize the timezone and see if that worked.
Even in the x86 emulator the difference for this is from 2+ms to no
longer measurable here, on less powerful ARM devices it's even more
extreme. This matters in particular for code creating many QTimeZone
instances, e.g. for calendaring.
Pick-to: 6.7 6.6 6.5
Change-Id: I5f175137b8b71816347a8debb492214427a51104
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Various parts of QTimeZone's code were, for no immediately apparent
reason, conditioned on !defined(QT_NO_SYSTEMLOCALE). All are in any
case conditioned on feature timezone; and none had any obvious
relationship with QLocale::system(). Assume this is a fossil left over
from initial development of timezone support and purge.
[ChangeLog][QtCore][QTimeZone] Some features are now available
whenever feature timezone is enabled, that were previously dependent
on system locale support.
Change-Id: I7f2246e17ace22d2aecc9286295ae522ee2a0f5f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The class had operator==() and operator!=() defined as public member
functions, so use QT_CORE_REMOVED_SINCE and removed_api.cpp to get
rid of these methods and replace them with hidden friends.
Extend unit-tests by using the helper functions from QTestPrivate.
Task-number: QTBUG-104111
Change-Id: Ib9ca613005e2f1521dea5e3cd9e2baa0b47fede4
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
While it would be perverse for availableTimeZoneIds() to list all
supported UTC-offset zone IDs, it makes reasonably good sense for its
offset-specific overload to include the ID QTimeZone would use for the
relevant UTC-offset, since passing this ID to the ID-based constructor
will indeed get a zone with this offset. In particular, it already
does include the offset-zone's ID if there is an IANA UTC-offset zone
with the given offset; and its list is apt to be empty otherwise.
Only applies to IDs we would in fact accept, checked with
offsetFromUtcString() to match the QTZ constructor's check.
Change-Id: I77bb60b166c3d3af5824d84952e1e10a5d32a5ad
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Principle of least surprise: prefer IANA IDs over synthesized ones.
This also aligns what id() returns more nearly with what
availableTimeZoneIds() reports. Amend some tests to match the new
behavior, extend one test to verify id-round-tripping (also for the
IANA zones) and another to verify single-digit offset IDs get
zero-padded.
Document the complications in how id() relates to what is passed to
the constructor. (It was already complicated; the present change just
aligns it better with IANA IDs, where possible.) Mention, in
availableTimeZoneIds(), that (and why) it only includes IANA's offset
IDs. Drive-by: fix a typo in another availableTimeZoneIds() overload's
doc.
[ChangeLog][QtCore][QTimeZone] When created from (only) a UTC offset,
or from (only) a non-IANA UTC-offset ID, a QTimeZone instance now uses
an IANA UTC-offset ID, where one is available with a matching offset.
Previously it used a synthesized UTC±hh[:mm[:ss]] one which would omit
trailing :00 for minutes or seconds, which the IANA ID may well
include.
Task-number: QTBUG-118586
Change-Id: Ifc4976f36361c830c88a8bef0e8b963fe5a2ab43
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The QTimeZone(id) constructor accepts these IDs, but
isTimeZoneIdAvailable() did not admit to this. Although we cannot
sensibly list all 183,047 of them in availableTimeZoneIds(), we should
not claim they are unavailable. The custom QTZ constructor needs to
know when the ID it's been given is an IANA one (to refuse to use it),
so it has to be able ask the backends for "is this IANA", so the UTC
backend still has to report these IDs as invalid, leaving the QDT
frontend to include the check for these offset zones.
Extend isTimeZoneIdAvailable() test to include every offset-zone's ID
within QTZ's recognized range of offsets. Although the actual range
accepted by offsetFromUtcString() is wider, bounded by ±24:59:59, the
constructor from offset seconds (rather than offset string) is bounded
by ±16 hours.
Pick-to: 6.6 6.5
Fixes: QTBUG-118586
Change-Id: Id9b378aee122ec841635584367022fcb47041fdd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The ID of the custom zone *must not* be an IANA ID, so naming the
variable ianaId was misleading. The declaration in qtimezone.h uses
zoneId, which is more appropriate, so change the docs and definition
to use that name instead. Also add emphasis where the doc says it must
not be an IANA ID.
Pick-to: 6.6 6.5
Change-Id: I55fbb748173b540741453db3f1e2492272635f9a
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Previously, it was left to the caller to guess.
Change-Id: Icc22b8c874046de78e16253cf0cc3ba2f334362b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's possible, as was (and still is) documented, at least on Windows,
for the backend to determine the system local time zone's properties
but not its IANA ID. (That involves an update to Windows introducing a
Windows zone ID unknown to the CLDR with whose data Qt was compiled.)
Formerly this lead to systemTimeZoneId() and systemTimeZone().id()
being inconsistent. Furthermore, either in this case or when the
system zone can't be determined, passing the return from
systemTimeZoneId() to the constructor got a valid QTimeZone that did
not faithfully represent the system's local time or the return from
systemTimeZone().
[ChangeLog][QtCore][QTimeZone] When unable to determine the IANA ID of
the system's local time zone, QTimeZone::systemTimeZoneId() now
returns empty instead of the "UTC" it formerly, and misleadingly,
returned. Passing the return to the QTimeZone constructor now
consistently produces the same as calling QTimeZone::systemTimeZone(),
whose id() now matches the return from QTimeZone::systemTimeZoneId().
This is independent of whether QTimeZone::systemTimeZone() is valid.
Change-Id: I55bbe3ea407ca38343a09da353d9336708747bf1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Also move some docs from asBackendZone() to systemTimeZone(), making
clear that the system zone object is current at the time of creation
and won't be updated if the system is reconfigured. Adapt some tests
to fail and make clear that the system is misconfigured if no valid
system zone is found.
[ChangeLog][QtCore][QTimeZone] If systemTimeZone() is unable to
identify a valid system time zone, it now produces a warning the first
time it encounters the problem.
Task-number: QTBUG-116017
Change-Id: Ia437d8a03ff3cbf2b2cd98e8a8c3aebe50c1ee32
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The QTzTimeZoneCache created one cache entry for every time zone
which was looked up, even if the code was invalid. This uses some
memory for each time zone code queried and thus allows DOS attacks
if user supplied time zone codes are parsed.
This patch prevents the creation of QTimeZonePrivate objects for
invalid time zone IDs.
Change-Id: I22007f6681bea54fa08639f4f786e1a49d10f920
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>
Clarify that a zone whose territory() is AnyTerritory may simply not
have a known association, or cover several territories.
Added more \sa links to territory(), where relevant.
Fix some surviving uses of country for territory.
Split some long lines.
Pick-to: 6.5 6.2
Change-Id: I9196f785afed9bc185a459608c5d9361127401cb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][Corelib][QTimeZone] On Unix (other than macOS and
Android), the TZ-DB backend has long accepted any well-formed POSIX
zone description as a time-zone ID. This is now reflected in
QTimeZone::isTimeZoneIdAvailable(), which previously claimed not to
accept these IDs. However, avaliableTimeZoneIds() still does not
attempt to construct all possible POSIX descriptors to include in its
return.
Change-Id: I1df8df0a4acaca9e70d72f13200b4c31305732f3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In so far as we support Darwin on tvOS or iOS, it surely makes more
sense to use the same code as on macOS for them. This will also avoid
further grumbles from the inanity 'bot about the use of the old define.
As a drive-by, make the #if-ery on newBackendTimeZone() consistently
use parentheses with defined.
Change-Id: I6099adfedfc42bba057c8cbfbb38574e2e5d80d7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The move-constructors for QTimeZone and QTimeZone::Data are trivial so
can be inlined. Requested by Marc Mutz in 6.5 API review.
Pick-to: 6.5
Change-Id: Id59dc95e0da061187d9db8cf0a5ab82fcece1694
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>
It's mentioned in some of the functions, but the type's documentation
should also mention it.
Change-Id: Ia8ceb21ff30df1b5933782ae7d8bebe9f436404c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Also save some wanton line breaks in \value directives.
Change-Id: I16e0798d7474febb7946ece0ad57c80476f9d9e2
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>
This appears to have been overlooked. It's just the copy-construction
of a QSharedDataPointer, which is declared noexcept, so transparently
safe.
Change-Id: I85e1f750be26dfa94d52dfc0b14efe9c1857d645
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
CodeChecker noted that both QDateTime::Data and QTimeZone have
incomplete rule-of-five method sets; and two of the former's methods
should be noexcept. Marc tells me the copy constructor can be
noexcept. Added the missing methods and noexcepts.
Change-Id: I8ddaa86207320606a890e90bd2b1593ee82f5a4a
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>
CodeChecker points out that QTimeZone::systemTimeZoneId()'s first
attempt saved its result in a const QByteArray, which consequently
wasn't moved from when returning. That doesn't make a huge difference
for a CoW, but might as well skip the const and let the compiler do
the natural thing.
Change-Id: I966c9137505a8188532b164524dd4e05c0b2ac53
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>
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>
As a drive-by, did also minor refactorings/improvements.
Task-number: QTBUG-98434
Change-Id: I81964176ae2f07ea63674c96f47f9c6aa046854f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
Apparently the class docs didn't get an update when systemTimeZone()
was added (at 5.5). Also add QCalendar to the \sa.
Prompted by Jaishree pointing out a typo ...
Pick-to: 6.3
Change-Id: If6d38040fff4badc3c0bb765889c1289c560c2b0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Given that at least one zone has a negative offset (so that it's in
standard time for most of the year, including summer, and
daylight-saving time relatively briefly during winter), QTimeZone's
docs should explain what that means.
Change-Id: I6649b4cdefbd685dc97bf85d957960da44d07aed
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
It is no longer handled separately from Android.
This effectively reverts commit 6d50f746fe05a7008b63818e77784dd0c99270a1
Change-Id: Ic2d75b8c5a09895810913311ab2fe3355d4d2983
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This reverts commit ec8808c3020abbc436f1a2d90fecf3245fd6417b 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>
When asked to read an OffsetFromUtc record, it was trying the IANA ID
it read in as a possible zone name. If the backend accepted the given
ID as a zone name, however, the result might not be an offset-from-UTC
zone. So extend the isValid() check it was doing on the result to at
least check the zone has no DST and matches the record's offset.
Change-Id: I46a95aeb2a4d66887fd56a58fa72fe5d3b568a00
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>
