summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/tools/qdatetime
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'origin/5.9' into 5.11Liang Qi2018-02-141-0/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/corelib/animation/qvariantanimation.cpp src/corelib/global/qglobal.cpp src/corelib/global/qlogging.cpp src/corelib/io/qprocess_win.cpp src/corelib/json/qjsonarray.cpp src/corelib/tools/qsimd_p.h src/corelib/tools/qtimezoneprivate_p.h src/corelib/xml/qxmlstream_p.h src/gui/kernel/qsimpledrag.cpp src/gui/kernel/qsimpledrag_p.h src/plugins/generic/generic.pro src/plugins/platforms/cocoa/qcocoamenu.mm src/widgets/styles/qmacstyle_mac.mm tests/auto/concurrent/qtconcurrentmap/BLACKLIST tests/auto/corelib/io/qfileinfo/tst_qfileinfo.cpp tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp tests/auto/gui/kernel/qwindow/BLACKLIST tests/auto/widgets/dialogs/qmessagebox/BLACKLIST Change-Id: I508d686cf20f7f8cc6a7119b9bc7c3bbb505c58e
| * Clean-up in QDateTime's parsing of ISODate{,WithMs}Edward Welbourne2018-02-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Actually check that there's a T where ISO 8601 wants it (instead of just skipping over whatever's there), with something after it; move some declarations later; add some comments; and use the QStringRef API more cleanly (so that it's easier to see what's going on). Simplify a loop condition to avoid the need for a post-loop fix-up. This incidentally prevents an assertion failure (which brought the mess to my attention) parsing a short string as an ISO date-time; if there's a T with nothing after it, we won't try to read at index -1 in the following text. (The actual fail seen had a Z where the T should have been, with nothing after it.) Add tests for invalid ISOdate cases that triggered the assertion. Task-number: QTBUG-66076 Change-Id: Ided9adf62a56d98f144bdf91b40f918e22bd82cd Reviewed-by: Israel Lins Albuquerque <israelins85@yahoo.com.br> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit a9c111ed8c30a5a8fec3f02244f0d5a4bd08e931)
* | Merge remote-tracking branch 'origin/5.10' into devLiang Qi2018-01-201-5/+7
|\ \ | | | | | | | | | | | | | | | | | | Conflicts: tests/auto/widgets/itemviews/qtreeview/tst_qtreeview.cpp Change-Id: If089d5010d15c33b3c1f13912d4386207456c1a9
| * | Skip a date-time test when we don't know what result it should giveEdward Welbourne2018-01-121-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The operator_eqeq(data13) test expected the local-time epoch and UTC epoch to agree precisely if the localTimeType set by the test's constructor says local time is UTC; however, when the local zone is *sometimes* ahead of (or behind) UTC, due to DST, localTimeType is duly set to indicate that, which doesn't preclude the zone agreeing with UTC at the epoch. This indeed happens for Europe/London, which agrees on the epoch but was ahead a few months later. So we can't determine what outcome to expect based solely on localTimeType, although we can be sure of a match when local time is UTC. So skip this test when local time isn't UTC (and document what's going on a bit better). Task-number: QTBUG-65435 Change-Id: Id9b8aa0402f2a2b410e0234f6eca4ab0d1010bc4 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | | Merge remote-tracking branch 'origin/5.10' into devLiang Qi2018-01-111-3/+0
|\| | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/3rdparty/harfbuzz-ng/src/hb-private.hh src/sql/doc/snippets/code/doc_src_sql-driver.cpp src/sql/doc/src/sql-driver.qdoc Change-Id: I38f0e82fcd37926cbf3c1915e009a731040d4598
| * | Merge remote-tracking branch 'origin/5.9' into 5.10Liang Qi2018-01-091-3/+0
| |\| | | | | | | | | | Change-Id: I840849c072075a69819eb185b20bc42c3de0f825
| | * Revert "Blacklist tst_QDateTime::operator_eqeq"Edward Welbourne2018-01-071-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove black-listing of test; the problem was due to misconfigured time-zone on the CI system - it was on some zone that presently coincides with UTC, not actually on UTC as supposed. This reverts commit 597b96b8fa2fc8b9331db8ecc85d742be83fbec5. Change-Id: I72ad1dfa38532362c05aef33cd874f7f79879a41 Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
* | | Merge remote-tracking branch 'origin/5.10' into devLars Knoll2018-01-022-2/+5
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf sc/corelib/io/qfsfileengine_p.h src/corelib/io/qstorageinfo_unix.cpp src/platformsupport/eglconvenience/qeglpbuffer_p.h src/platformsupport/input/libinput/qlibinputkeyboard.cpp src/platformsupport/input/libinput/qlibinputpointer.cpp src/plugins/platforms/cocoa/qcocoamenu.mm src/plugins/platforms/ios/qiosscreen.h src/plugins/platforms/ios/qioswindow.h src/plugins/platforms/ios/quiview.mm src/printsupport/dialogs/qpagesetupdialog_unix_p.h src/printsupport/dialogs/qprintpreviewdialog.cpp src/printsupport/widgets/qcupsjobwidget_p.h src/widgets/widgets/qmenu.cpp tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp tests/auto/widgets/itemviews/qtreeview/tst_qtreeview.cpp Change-Id: Iecb4883122efe97ef0ed850271e6c51bab568e9c
| * | Merge remote-tracking branch 'origin/5.9' into 5.10Lars Knoll2017-12-301-0/+3
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf mkspecs/win32-g++/qmake.conf src/corelib/global/qglobal_p.h src/corelib/global/qoperatingsystemversion_p.h src/corelib/io/qfilesystemengine_win.cpp src/network/bearer/qbearerengine.cpp src/platformsupport/input/libinput/qlibinputpointer.cpp src/sql/doc/snippets/code/doc_src_sql-driver.cpp src/widgets/kernel/qwidget_p.h src/widgets/kernel/qwidgetwindow.cpp src/widgets/styles/qfusionstyle.cpp tests/auto/corelib/io/qfileinfo/tst_qfileinfo.cpp Change-Id: I80e2722f481b12fff5d967c28f89208c0e9a1dd8
| | * Blacklist tst_QDateTime::operator_eqeqJoni Jantti2017-12-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | This autotest fails on the new Ubuntu 16.04 template with UTC timezone in the system settings. Task-number: QTBUG-65435 Change-Id: I397f01ab3fed354a4eeec8b05415226a75fce5a1 Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
| * | Special-case parsing of Zulu time-zone in date-timesEdward Welbourne2017-11-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When parsing a date-time's zone, a stray Z denotes UTC (a.k.a. Zulu time), despite not being a valid name for the zone. Clients parsing such date strings had to treat the Z as a literal, rather than a zone-ID, but then they got back a LocalTime instead of the UTC the string actually described. So teach QTimeZoneParser to handle this special case and adapt an existing test (that used a time ending in Z, but had to treat it as a local time) to check this works. [ChangeLog][QtCore][QDateTime] When parsing a time-zone, "Z" is now recognized as an alias for UTC. Change-Id: Ib6aa2d8ea2dc6b2da526b39aec74dbc007f90fd8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | | Raise the upper bound on years to 9999Edward Welbourne2017-11-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Test-case taken from bug-report; fits in as an easy row in an existing data-driven test. Add similar tests for date-time and time; and an isValid test on the end of year 9999. The date-time parser was using the end of year 7999 as maximum value for dates and date-times; extend this to year 9999, as I can see no reason not to. [ChangeLog][QtCore][QDateTime] Years up to 9999 can now be parsed without error (previously 8000 and beyond were treated as invalid) in all formats (not only in ISO format). Widgets handling dates now support dates to 9999, likewise. Task-number: QTBUG-64401 Change-Id: I518cfa6c2cb4ecc5a85b896dc9e56b4fdd8a8bb1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | | Remove references to obsolete platformsJake Petroules2017-11-051-21/+0
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | ultrix and reliant have not seen a release since 1995. dgux not since 2001. bsdi not since 2003. irix not since 2006. osf not since 2010. dynix... unclear, but no later than 2002. symbian needs no mention. All considered obsolete, all gone. sco and unixware are effectively obsolete. Remove them until someone expresses a real need. Change-Id: Ia3d9d370016adce9213ae5ad0ef965ef8de2a3ff Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Clean-up in QDateTime's parsing of ISODate{,WithMs}Edward Welbourne2017-08-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Actually check that there's a T where ISO 8601 wants it (instead of just skipping over whatever's there), with something after it; move some declarations later; add some comments; and use the QStringRef API more cleanly (so that it's easier to see what's going on). Simplify a loop condition to avoid the need for a post-loop fix-up. This incidentally prevents an assertion failure (which brought the mess to my attention) parsing a short string as an ISO date-time; if there's a T with nothing after it, we won't try to read at index -1 in the following text. (The actual fail seen had a Z where the T should have been, with nothing after it.) Add tests for invalid ISOdate cases that triggered the assertion. Change-Id: Ided9adf62a56d98f144bdf91b40f918e22bd82cd Reviewed-by: Israel Lins Albuquerque <israelins85@yahoo.com.br> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Add a date-time test for time-zones near epoch and odd transitionsEdward Welbourne2017-07-311-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | Check we do handle DST after epoch and don't before. Check we do notice various unusual transitions. Check we do handle non-whole-hour-offset zones. (Unfortunately, MS-Win lacks data for some of the zones and is wrong about the two date-line crossers, so we skip those for it.) Change-Id: If420d61b9db7f914ca25c22297c16e917ad2307a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | tst_QDateTime::toTimeSpec(): verify round-tripping works cleanlyEdward Welbourne2017-07-071-0/+4
| | | | | | | | | | Change-Id: I811fa4249dae923e5e4e434910d8bf96c15bff25 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Clarify tst_QDateTime::fromStringToStringLocale() using a macroEdward Welbourne2017-07-071-7/+9
| | | | | | | | | | | | | | | | | | | | | | Separate the part varying between tests from the common form of all the tests, so the reader can see the common pattern and know for sure that there's not a typo or copy-and-paste glitch. Change-Id: I3145a26ab42c104eb27756d906ac87f937024bad Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | QDateTimeParser: implement parsing of time-zone specifiersEdward Welbourne2017-06-201-4/+0
|/ | | | | | | | | | | | | | | | | The serialization of date-times understood time-zones (indicated by a 't' in a format string) but the parsing didn't (so viewed the 't' as a literal element in the format string, not matched by the actual zone it needs to parse), although some tests expected it to. This made round-trip testing fail. Implemented parsing of time-zones. Re-enabled the formerly failing tests. [ChangeLog][QtCore][QDateTime] Added support for parsing of time-zones. Task-number: QTBUG-22833 Change-Id: Iddba7dca14cf9399587078d4cea19f9b95a65cf7 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Merge remote-tracking branch 'origin/5.8' into 5.9Liang Qi2017-03-131-0/+73
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: examples/network/network.pro mkspecs/features/mac/default_post.prf src/corelib/io/qfilesystemengine_win.cpp src/corelib/io/qprocess.cpp src/corelib/io/qprocess.h src/corelib/io/qprocess_p.h src/corelib/io/qprocess_unix.cpp src/corelib/io/qprocess_win.cpp src/corelib/thread/qmutex.cpp src/platformsupport/fontdatabases/windows/windows.pri src/plugins/platforms/eglfs/eglfsdeviceintegration.pro tests/auto/corelib/io/io.pro Change-Id: I8a27e0e141454818bba9c433200a4e84a88d147e
| * Fix parsing of day-of-week names that start with another nameThiago Macieira2017-02-281-0/+50
| | | | | | | | | | | | Task-number: QTBUG-59159 Change-Id: I95c9e502ccc74af3bcf0fffd14a69e0cd27ce96b Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
| * QDateTime: Fix clearing the ShortData flag in setMSecsSinceEpochThiago Macieira2017-02-241-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.8' into 5.9Liang Qi2017-02-241-13/+15
|\| | | | | | | | | | | | | Conflicts: mkspecs/features/moc.prf Change-Id: Ia71c8e3b3185f7c999bf226d0675051b10b8740b
| * Make sure to use C locale during time tests that assume itEdward Welbourne2017-02-201-13/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.8' into 5.9Liang Qi2017-02-161-13/+25
|\| | | | | | | | | | | | | | | | | Conflicts: src/corelib/plugin/qlibrary_unix.cpp src/plugins/platforms/xcb/qxcbconnection.cpp tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp Change-Id: I632c400d909f8c204f55743aadc7886af2f15dfb
| * Package transient zone setting in test to ensure restore on failEdward Welbourne2017-02-151-13/+25
| | | | | | | | | | | | | | | | | | | | | | 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>
* | Remove two unused static methods of QDateTimePrivateEdward Welbourne2017-01-121-2/+0
| | | | | | | | | | | | | | ... along with the two matching unused methods of QDateTime's test. Change-Id: Id11a4b1b0132587f0df451d49c0043e9425d87ad Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | QDateTime test: clarify overflow-checkEdward Welbourne2017-01-021-6/+4
| | | | | | | | | | | | | | | | | | | | | | An overflow-check needed the datum for the "min" test to be minus the datum for the "max" test; so explicitly make the former use -max() instead of synthesising it as min()+1. This simplifies the explanation of why that's needed, too. Clarify the overflow-check's comment at the same time. Change-Id: I41f56764fdf5e8c749bfae7a685e5fb77d37b3a8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Fix handling of time-zones in QDateTime::toString(Qt::TextDate)Edward Welbourne2016-12-141-0/+44
| | | | | | | | | | | | | | | | | | | | | | Previously, a zone-based time would claim to be GMT, rather than identifying its zone properly. Sadly, testing this reveals that proprietary operating systems don't handle abbreviations ideally. Task-number: QTBUG-57320 Task-number: QTBUG-57298 Change-Id: I8d8b7fffdbf65ac6178a65f5fc2df4d25afb1a14 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Fix QDateTime::toString(Qt::ISODate)'s handling of Qt::TimeZoneEdward Welbourne2016-12-141-0/+23
| | | | | | | | | | | | | | | | | | | | When the time is specified relative to a zone, the ISO date produced lacked its offset suffix; all zones were treated as if they were local time. Handle zone as for an offset from UTC and ensure we do set the date-time objects's offset from UTC when it's zone-based. Change-Id: I7c9896bb8ec0a9d89df14a6e94b005174ab9e943 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | QDateTime, QTimeZone: fix mappings from zone time to UTCEdward Welbourne2016-12-121-2/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Such mappings are ill-defined in the presence of daylight-savings time (DST); at its transitions, you need information about whether DST is active or not to determine the correct UTC value. Existing code did not have a way to be told that hint, so could not be correct. Fixing this required changing the (thankfully private) APIs by which QDateTime accessed QTimeZone's information stipulated by zone time. In QDateTime, this required propagating the needed hint, when DST status was known. QAndroidTimeZonePrivate overloaded QTimeZonePrivate::dataForLocalTime with an implementation that works whenever !hasTransitions(); the base implementation handled this case lamely, so I've moved the Android implementation there, to have only one place for both re-writes. Amended tst_QDateTime's expected failures; passing a date and time to the constructor *is* ambiguous when the moment indicated is in a transition. I have changed which way we resolve that ambiguity. Added round-trip test of QDateTime's fromMSecs/toMSecs (but as a QTimeZone test, since that's what's actually getting tested), based on a test-case from Marko Kangas. Initially failed for various zones, each at one hour-offset; and, on some platforms, for some zones, at all offsets. These last revealed that a platform may claim to have zone information yet, for some zones, lack it (or have very incomplete information). In each case, despite this, the platform does give offsetFromUtc(). (The test also found another pre-existing bug on Linux; fixed in an earlier commit.) To accommodate these gaps in transition data, the transition-based code now falls back to the offsetFromUtc()-based code (used when there are no transitions) if it can't find a previous transition (which, in any case, it needs to do its job). Task-number: QTBUG-56460 Task-number: QTBUG-56397 Task-number: QTBUG-52284 Change-Id: I2f7422a9e9d3767940b1901d887c6a2c1f36ac9f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add Qt::ISODateWithMs date format, with support in QTime/Date/DateTimeTor Arne Vestbø2016-10-201-8/+18
| | | | | | | | | | 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>
* Round to nearest millisecond in QDateTime::fromCFDate()Tor Arne Vestbø2016-10-021-4/+7
| | | | | | | | | | | | 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>
* QDateTime: introduce {to,from,set,current}SecsSinceEpochThiago Macieira2016-06-221-65/+69
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* QtCore: Remove Windows CE.Friedemann Kleint2016-03-301-28/+4
| | | | | | | | | Remove QSysInfo::WV_CE_5/6 enumeration values, #ifdef sections for Q_OS_WINCE and wince .pro file clauses in library, examples and tests. Task-number: QTBUG-51673 Change-Id: Ib63463445f3a26e04d018b193e4655030002f5f9 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-02-291-2/+0
|\ | | | | | | | | | | | | Conflicts: tests/auto/corelib/io/qprocess/tst_qprocess.cpp Change-Id: Ib6955eb874b516b185b45d6c38cec646fbaa95f4
| * Remove a mis-placed QSKIP().Edward Welbourne2016-02-261-2/+0
| | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.6' into devLiang Qi2016-02-021-3/+67
|\| | | | | | | | | | | | | | | | | Conflicts: config.tests/unix/compile.test src/plugins/platforms/cocoa/qcocoahelpers.mm src/tools/qlalr/cppgenerator.cpp Change-Id: I0103ca076a9aca7118b2fd99f0fdaf81055998c3
| * Don't let a good day cause date-time parser to forget a conflict.Edward Welbourne2016-01-291-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Add DST-change test for a date derived via .toLocalTime().Edward Welbourne2016-01-261-0/+24
| | | | | | | | | | | | | | | | | | 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>
| * Test .addDays() and .addMonths() are sensible around DST changes.Edward Welbourne2016-01-261-2/+40
| | | | | | | | | | | | Task-number: QTBUG-49008 Change-Id: Ie3bf9dfeb67c96b18320e18c14b9680f03cb98e9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Merge remote-tracking branch 'origin/5.6' into devLiang Qi2016-01-261-9/+6
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/android/jar/src/org/qtproject/qt5/android/QtActivityDelegate.java src/dbus/qdbusconnection_p.h src/dbus/qdbusintegrator.cpp src/dbus/qdbusintegrator_p.h tests/auto/corelib/io/qdir/qdir.pro tests/auto/corelib/io/qiodevice/tst_qiodevice.cpp Change-Id: I3d3fd07aed015c74b1f545f1327aa73d5f365fcc
| * Autotest: make tst_QDateTime pass when LC_TIME != en_USThiago Macieira2016-01-221-9/+6
| | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge "Merge remote-tracking branch 'origin/5.6' into dev" into refs/staging/devLiang Qi2016-01-261-54/+133
|\ \
| * | Merge remote-tracking branch 'origin/5.6' into devLiang Qi2016-01-211-54/+133
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qiodevice_p.h src/corelib/kernel/qvariant_p.h src/corelib/tools/qsimd.cpp src/gui/kernel/qguiapplication.cpp tests/auto/network/socket/qtcpsocket/tst_qtcpsocket.cpp Change-Id: I742a093cbb231b282b43e463ec67173e0d29f57a
| | * Expand springForward_data() to cover a few more time-zones.Edward Welbourne2016-01-201-3/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * Be fussier about setting tst_QDateTime's globals.Edward Welbourne2016-01-201-14/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * Nomenclature corrections relating to CET.Edward Welbourne2016-01-201-37/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * Don't pretend we know what DST to use for an offset date.Edward Welbourne2016-01-121-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Add Intel copyright to files that Intel has had non-trivial contributionThiago Macieira2016-01-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Updated license headersJani Heikkinen2016-01-212-34/+24
|/ / | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-15 06:06:50 +0000