Unlike setTimeSpec, this forgot to clear the bit when detaching. So it's
possible that some further use of the flags could incorrectly conclude
that the data was short and then proceed to corrupt the pointer.
The example from QTBUG-59061 caused this because toUTC() -> toTimeSpec()
calls setMSecsSinceEpoch which left the bit set; then addDays() calls
setDateTime(), which calls checkValidDateTime() and that corrupted the
pointer. This problem was more visible on 32-bit systems because no
QDateTime was short (except for default constructed ones), but it
can happen on 64-bit with sufficiently large dates.
Task-number: QTBUG-59061
Change-Id: Ibc5c715fda334a75bd2efffd14a562a375a4e69b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Some format and parse tests for time and date-time depended on locale
but had test data for the C locale (so fail if the test-environment
has, e.g., LANG=de_DE@utf8). So impose the C locale (until Qt 6).
The date-time test did *some* attempts at fixing for locale, but
failed to handle am/pm; and we do have "### Qt 6" comments in
Q(Date|Time)+::fromString indicating that we intend to switch these
methods to use the C locale by default (which shall fix this once and
for all). So rip out the incomplete localization now and test we work
properly at least when the locale used *is* C. Add a comment to the
matching QDate test to rip out its (presently adequate) matching code
once we do get to Qt 6 and make fromString() use the C locale.
QDateTimeParser uses systemLocale(), which is initialized the first
time it gets accessed; so we need to frob the locale *early*; doing so
in the test-class constructor is about as early as we conveniently
can; and seems to work (while doing it in individual tests does not).
(There is no point rolling back at the end; the QSystemLocale global
has been set up by then, so the roll-back would merely leave the
global out of sync with setlocale() and the environment.)
Task-number: QTBUG-58728
Change-Id: Ifa6778a80276050a099387a6dab15a1096be7561
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
tst_QDateTime::operator_insert_extract() was setting the time-zone and
taking care to restore it at the end of the test; however, if the test
were to fail, the restore would be skipped. Package the zone-setting
and restore in a class instance, so that premature return can't bypass
the restore.
Change-Id: I3df63260da17e481ef4d0d107d9f0fdea3e147e7
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
The Qt::ISODate format strips milliseconds, so a new format is introduced
that keeps the milliseconds. A new format was chosen over fixing the
existing format due to the behavioral change of suddenly having ms
as part of Qt::ISODate.
Change-Id: If8b852daed068cce8eee9b61a7cd4576bc763443
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
CFAbsoluteTime is measured in seconds, represented by a double,
so when converting milliseconds to CFAbsoluteTime we may get a
slight error due to missing precision in double to represent
the milliseconds exactly. By rounding to the closest millisecond
when converting back, we avoid truncating and being one ms off.
Change-Id: If1e99f97b000fb8cb893ddfc5d7ba81096c0ea88
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
These new functions use a 64-bit integer in the API, instead of the
broken 32-bit unsigned integer that the previous xxxTime_t functions
used. That was a design flaw when the API was introduced back in Qt 4.2,
so I'm deprecating the API and slating it for removal in 6.0.
The changes to qfilesystemmetadata_p.h and quuid.cpp are necessary to
build the bootstrap library. The rest of the adaptation to the new API
will come in the next commit.
[ChangeLog][QtCore][QDateTime] Introduced toSecsSinceEpoch,
fromSecsSinceEpoch and setSecsSinceEpoch functions, which use 64-bit
integers to represent the number of seconds.
[ChangeLog][QtCore][QDateTime] The toTime_t, fromTime_t and setTime_t
functions are deprecated and will be removed in Qt 6.0. For new code,
use the equivalent functions with "SecsSinceEpoch" in the name, or the
equivalent ones with millisecond accurancy that have existed since
Qt 4.7.
Change-Id: Ib57b52598e2f452985e9fffd145a355d0e7ff48d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
It made us skip the rest of the test, not just the small set of
sub-tests that were conditioned by the if () in whose else it sat.
Change-Id: I5e914e0aeb9d5ba44b21966d071aaccbc590365d
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Setting conflicts to isSet & DaySection cleared it if we hadn't seen
the day stipulated, even if there had been a conflict (e.g. over year)
before we hit the day-of-week that didn't match the (unset, so
defaulting to) 1st of the month. Explicitly test for conflict and
only set conflicts (to true) if there is a conflict. Added regression
test.
Change-Id: I7363eb66a8bb808d341738d14969039834f50db8
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Uses a time derived via .toUTC() to ensure the .toLocalTime() comes
out at the time we expect.
Task-number: QTBUG-49008
Change-Id: I2005127929c7eab1b7a3cbaba8d21df8c9585d17
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QDateTime::toString for Qt::TextDate unconditionally uses the system
locale (because QDate::shortDayName and QDate::shortMonthName do).
Setting the default QLocale has no effect. If you ask me, those two
QDate methods are buggy, but they are documented that way.
Change-Id: I408dcb81ba654c929f25ffff1427366b04da5a43
Reviewed-by: Edward Welbourne <edward.welbourne@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I wrote a script to help find the files, but I reviewed the
contributions manually to be sure I wasn't claiming copyright for search
& replace, adding Q_DECL_NOTHROW or adding "We mean it" headers.
Change-Id: I7a9e11d7b64a4cc78e24ffff142b506368fc8842
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some
exceptions, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one
(in those files which will be under GPL 3 with exceptions)
Change-Id: I42a473ddc97101492a60b9287d90979d9eb35ae1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
The important one is EET, for the benefit of our CI system; but other
European zones and the USA's coastal zones likely have enough hackers
in them to make this worth checking.
Change-Id: Idcc703bce29808e1a0a6279680cc8d3cbed38dac
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Time zones change on the whim of politicians. Consequently, we can
seem to be in CET/CEST or on UTC (because we tested sample dates when
our zone coincided) when we aren't (i.e. we're in a materially
different zone at the time probed by some particular test). Make the
initialization of the globals that test this more robust against
governmental meddling and document the unfixable problem with Algeria:
a DST transition *on the epoch*.
Change-Id: I17c5c81d339b80af12f4ffab367e28052dd6c2fa
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There are several European time zones; the only one relevant to the
tests here is CET. They won't work with WET, GMT or EET. So name
them and related variables for CET, not for Europe.
CET's summer-time isn't called CST; and the (existing) spring forward
test works only in CET/CEST, not elsewhere in Europe.
Change-Id: I55c7544bf792de7495700b749b935ec534831d8b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When QDateTime::addDate() and friends sanitize their end-state, they
were using the DST status of their start-state (if known) to control
it. This lead to misguided results and, in particular, inconsistent
results given that a raw-constructed QDateTime comes into being
ignorant of its DST, while a .toLocalTime() one knows its DST.
Furthermore, the code to do this was triplicated, tricky and poorly
explained. So pull it out into a local static function and explain
what it's doing, and why, more clearly and only once.
Task-number: QTBUG-49008
Change-Id: Ia4bb3c5e9267fff8bb963ea705267998218ed623
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Widen its interval (to work in more TZs) and test spring as well as
autumn. Anywhere that does have a DST transition probably has it
between August and December; and there's no benefit to using a narrow
window.
There's also no sense skipping the test if we don't know there's a DST
transition: the test should still work, it just won't be testing
anything (about DST transitions).
Combine date and time checks into date-time checks, so that, when one
of them fails, QCOMPARE lets us know how the other changed, too.
Task-number: QTBUG-49008
Change-Id: I145b939ffef0dd0b54fd0e3cdf72a159c57ec00b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Test that stepping into the missing hour lands us somewhere sane.
Check that raw instance and product of .toLocalTime() agree.
Task-number: QTBUG-49008
Change-Id: I430382ae223bcb43b151d2d6054ecbdd7edc8a47
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
warning: 'typemsg1' may be used uninitialized in this function [-Wmaybe-uninitialized]
Change-Id: Ie68d279eccb003a2ca5a0116eea336cbc8776660
Reviewed-by: Edward Welbourne <edward.welbourne@theqtcompany.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Use QByteArray/QString addition instead in loops and for
test row names.
Change-Id: Ieffb429efdc14aa5932b3fcdef5a18e13a62d35f
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Use character literals where applicable.
Change-Id: I1a026c320079ee5ca6f70be835d5a541deee2dd1
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
The timeZone() function used to assert when called on such an object
(or, for a release build, return an invalid time zone).
Change-Id: I6ae8316b2ad76f1f868e2498f7ce8aa3fcabf4a6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The keyword no longer has a meaning for the new CI.
Change-Id: Ibcea4c7a82fb7f982cf4569fdff19f82066543d1
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
We have at least 5 different (but equal) implementations of a wrapper
in Qt, and some code uses explicit NSAutoreleasePools. Having a shared
implementation lets us clean up things a bit and makes it easier to
reason about which pools are actually needed.
Change-Id: I2fd8eefc3ae7308595ef9899b7820206268362a5
Reviewed-by: Tim Blechmann <tim@klingt.org>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Let's not try to to compare our QTimeZone handling with the system one.
Our handling goes beyond the range of the POSIX APIs, so that's a recipe
for error.
Change-Id: Iee8cbc07c4434ce9b560ffff13ca4a4f335bdbae
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
The refactoring from a8c74ddcf7 commit
exposed more issues in the Windows API. There were already quite a few
QEXPECT_FAIL for this, so this isn't new.
For example, localtime(1351386000) on the Central European Timezone
should be "Sun Oct 28 02:00:00 CET 2012" (the second occurrence of 2
am), but the Windows API returns tm_isdst = 1 (i.e., still in the CEST
timezone) and that's incorrect.
Change-Id: I1bc63ac99b1d67b55d783f9606e5c59b24223b13
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
In QtScript we use the msecs since epoch conversion (JS date is based on
the concept). After a8c74ddcf7 the date
conversion test in qtscript started to fail. Instead of relying on the
code working by chance, simply update the date when setting it with
setMSecsSinceEpoch.
Task-number: QTBUG-44885
Change-Id: I9f95c9cdccea52e7d1f808f3cb9e18570ef0df13
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When timezone support for QDateTime was added, we decided it was a good
idea to delay creating the QTimeZone object and checking that the time
is valid in that timezone (including for local time) until the user
requested that information. Unfortunately, QExplicitlySharedDataPointer
returns a non-const T* in operator->(), which meant we were accidentally
modifying the d pointer's contents in const methods, which in turn means
those const methods were not thread-safe when operating on the same
object.
This commit changes the d pointer to QSharedDataPointer, which is safer
in this regard and pointed out where the issues with constness were
located. Since we can't lazily calculate QTimeZone anymore, we need to
do it whenever the date, time or offset changes.
Task-number: QTBUG-43703
Change-Id: Ic5d393bfd36e48a193fcffff13b9686ef4ef1454
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Those QTimeZones failed to convert to other timezones because the data()
virtual function was never overridden and reimplemented. That meant all
QUtcTimeZonePrivate objects were *really* UTC, with no offset.
Task-number: QTBUG-44600
Change-Id: Ia0aac2f09e9245339951ffff13c5294bb783c674
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
Added support on QDateTime::fromString to read correctly dates on ISO
format with Time zone designators at format [+-]HH
Change-Id: Ied5c3b7950aee3d0879af0e05398081395c18df5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
