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>
The tests for toString/fromString previously didn't run tests
for timezones with hh:mm where mm != 00.
Change-Id: I74da99c5b6890f46ce06446084a8129b4cbc7a02
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: John Layt <jlayt@kde.org>
Conversion from UTC to local time will result in same datetime value,
if local time is in UTC.
Change-Id: Icd4ea57cb46cc97bcc8fce4f4e579bf64a4d4b10
Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
Explicitly check that the QTimeZone is valid before trying to use it.
Change-Id: Iec415a2cb07071502fe71ee5ac92a7657e818f99
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There was a comment about the test failing for max() because of an
overflow. That happens if you're at UTC or ahead of it (to the East of
the Prime Meridian), which is how this test usually gets run (UTC,
Europe/Oslo, Europe/Helsinki, Pacific/Auckland). But if you're behind
UTC (to the West of the Prime Meridian), then the overflow happens for
min().
Change-Id: Iebba49d1303e9f18f5038f5cf23c77bf83e5fd4b
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
For the conflicts in msvc_nmake.cpp the ifdefs are extended since we
need to support windows phone in the target branch while it is not there
in the current stable branch (as of Qt 5.2).
Conflicts:
configure
qmake/generators/win32/msvc_nmake.cpp
src/3rdparty/angle/src/libEGL/Surface.cpp
src/angle/src/common/common.pri
src/corelib/global/qglobal.h
src/corelib/io/qstandardpaths.cpp
src/plugins/platforms/qnx/qqnxintegration.cpp
src/plugins/platforms/qnx/qqnxscreeneventhandler.h
src/plugins/platforms/xcb/qglxintegration.h
src/widgets/kernel/win.pri
tests/auto/corelib/thread/qreadwritelock/tst_qreadwritelock.cpp
tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp
tests/auto/gui/text/qtextdocument/tst_qtextdocument.cpp
tools/configure/configureapp.cpp
Change-Id: I00b579eefebaf61d26ab9b00046d2b5bd5958812
The private method dateForLocalTime() was not checking that transitions
were valid, resulting in infinite looping when a time zone didn't have
any future transitions.
Change-Id: I0e5d07063861778dd86056a80c36fdd9f9d36133
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
We must not include qt_windows.h in public headers,
otherwise we're cluttering the environment with a colorful
bouquet of Windows API preprocessor macros and typedefs.
Task-number: QTBUG-34058
Change-Id: I415717ea2a47f39e7f4b7ce1c1df9d49afc99278
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
