summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/time
Commit message (Collapse)AuthorAgeFilesLines
* Add unit tests for qdatetimeparserAndreas Buhr2020-10-236-0/+89
| | | | | | | | | | | | | The qdatetimeparser was not tested explicitly so far, but only implicitly in tst_qdate / tst_qdatetime / tst_qdatetimeedit etc. This made it difficult to test some corner cases, especially in the context of unfinished dates, i.e. dates which are invalid, but could become valid by adding more characters. This is used to validate user input in qdatetimeedit. Task-number: QTBUG-84334 Change-Id: I27202849abb1b7cad96d3e25f7ac81ce85272b2a Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Add unit test for malformed RFC2822 datesAndreas Buhr2020-10-221-1/+11
| | | | | | | | | | | RFC2822 requires times to be in the format 'HH:mm' or 'HH:mm:ss'. We did not have unit tests to check that malformed RFC2822 dates are rejected. This patch adds such unit tests for truncated hours/minutes/seconds. Change-Id: Id5b9390112e633e617722439ad59439e6aeba841 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix blatant typo in QTimeZone testEdward Welbourne2020-10-191-8/+6
| | | | | | | | | | | This revealed that the test was always broken; it had simply never actually been checked. Done-with: Andreas Buhr <andreas.buhr@qt.io> Change-Id: I85ac7ba30738fa3b41bf8440a059ee3fabb4726b Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
* Check time-text is long enough while checking for its colonsEdward Welbourne2020-10-193-1/+7
| | | | | | | | | | Added some tests that trigger an assert without this check. (Drive-by: renamed one QTime test to match its QDate(Time)? counterparts.) Change-Id: I3d6767605fdcca13a9b4d43a32904f584eb57cf9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
* Check validity before adding to a QDateTimeEdward Welbourne2020-10-091-2/+44
| | | | | | | | | | | QDateTime's addDays(), addMonths() and addYears() neglected to check for validity before doing their job, with the result that they could produce "valid" (but wildly inappropriate) results if used on an invalid date-time. Added tests for this case (and the boundary). Change-Id: I7b0d638501cb5d875a678cde213547a83ed7529e Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Check against {und,ov}erflow in more QDateTime methodsEdward Welbourne2020-10-091-18/+60
| | | | | | | | | | QDateTime's range of possible values is wider than anyone generally needs, but let's not do confusing things when someone does overflow it. Change-Id: Ifbaf7a0f02cd3afe7d3d13c829bf0887eba29f7f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Check value is in range when setting a QDateTimeEdward Welbourne2020-10-091-11/+31
| | | | | | | | | | | | | | | | | | | Previously, a QDate representing more than about 0.3 gigayears before or after the epoch would overflow the millisecond count and produce a "valid" date-time that didn't represent the date and time passed to its constructor. Changed to detect such overflow and produce an invalid date-time instead, if it happens. Corrected some tests that wrongly expected to be able to represent extreme date-time values with every time-spec. The (milli)seconds since epoch are from UTC's epoch, so converting to another offset, zone or local time may give a value outside the actual range. Added some tests for the actual exact bounds. Task-number: QTBUG-68855 Change-Id: I866a4974aeb54bba92dbe7eab0a440baf02124f0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Allow millisecond-overflow when the result remains validEdward Welbourne2020-10-072-4/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even before adding support for fractional hours, a fraction of a minute might potentially have represented a whole number of seconds by a fractional part that, due to rounding, was less than the whole number of seconds by less than half a millisecond. Previously, the parsing would have clipped the fractional part at 999 milliseconds, in the preceding second, instead of correctly rounding it up to the whole second. For QTime::fromString(), which can't represent 24:00, and for TextDate, which doesn't allow 24:00 as a synomym for the next day's 0:0, applying such rounding to 23:59:59.999999 would produce an invalid result from a string that does represent a valid time, so use the nearest representable time, as previously. Added some tests and amended others. [ChangeLog][QtCore][QDateTime] QDateTime and QTime, in fromString() with format ISODate or TextDate, now allow a fractional part of the hour, minute or seconds to round up to the next second (hence potentially into the next minute, etc.) when this is the closest representable value to the exact fractional part given. When rounding up would turn a valid result into an invalid one, however, the old behavior of clipping to 999 milliseconds is retained. Change-Id: I8104848d246cdb4545a12819fb4b6755da2b1372 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
* Use start of day when wrapping 24:00 to the next dayEdward Welbourne2020-10-071-0/+5
| | | | | | | | | | | | | | | Previously we used 0:0 on the next day, which might fall in a fall-back's gap. [ChangeLog][QtCore][QDateTime] When fromString() reads 24:00 in ISO format, it now uses the start of the next day, rather than 0:0 on the next day. This only makes a difference if the next day's first hour is skipped by a time-zone transition. Change-Id: Ib81feca5dc09fa735321b6ab76d5d118d6db6fd2 Reviewed-by: Andreas Buhr <andreas.buhr@qt.io> Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Handle trailing cruft consistently in Qt::DateFormat parsingEdward Welbourne2020-10-031-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously the ISO time format would tolerate trailing cruft at the end in various cases even though there might be an offset specifier after the time, which should *not* be separated from it by anything (not even the spaces we originally planned to still tolerate). The RFC date format is forgiving about space, as is suitable for parsing of RFC-822 headers, but the other formats should match the handling in QDateTimeParser, which rejects any dangling cruft. At the same time, since this required a re-write of fromIsoTimeString() in any case, add support for the ISO format that gives the hour a fractional part and skips minutes and seconds. Previously we only had support for fractional minutes (with no seconds). The hour without even a fractional part is also valid. Reworked the documentation of Qt::DateFormat as it was wrong in places, inconsistent in its formatting and incomplete. Adjusted some tests to match the new behavior. A fraction separator with no following digits should have been recognized as an error previously and now is. [ChangeLog][QtCore][QDateTime] The ISODate and ISODateWithMs formats now reject trailing cruft (including spaces) at the end of a time string. They also gain support for parsing hour-only formats, including the hour-with-fractional-part format. Task-number: QTBUG-86133 Change-Id: I38ad1479ae033407f7df97ffbeb7c4bcd463d04a Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Rework a test, eliminating some needless conversion via stringsEdward Welbourne2020-10-021-35/+15
| | | | | | | | | | | | | | The name toSecsSinceEpoch() gave no hint to the fact that the test was, in fact, *also* testing round-tripping of the ISODateFormat. Since there are other tests for string conversion, make this a simple test of toSecsSinceEpoch(). It did the round-tripping via two methods with overly-terse names that might just as well be local lambdas - now redundant, so removed. Change-Id: I1e4fb1cc90224312c995596a8f3fe2bc5d9dfa15 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Give some QTime test-cases more informative namesEdward Welbourne2020-10-011-11/+19
| | | | | | | | | Also drop superfluous trailing 0s from QTime's constructor and add space after commas. Change-Id: Ie3ae87fd497456d6447c55e5d2c808ef59c9768d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
* QDateTime change documentation to reflect usage of C localeAndreas Buhr2020-09-231-0/+1
| | | | | | | | | | In the past, string formatting and parsing was done in the users locale. Now, the C locale is consistently used in QDate(Time) and localized functions are offered in QLocale. This patch reflects this change in the documentation. Change-Id: I81afda9063fa232d06841d63f69e19b49f8083f3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use same-msecs optimization more in QDateTime comparisonEdward Welbourne2020-09-231-3/+17
| | | | | | | | | | | | QDateTime's comparisons just compare milliseconds when both values are local times and their statuses (hence DST-ness) match. It can do the same for time-zones. While doing the same for UTC and fixed offsets wins nothing, it also costs nothing, given that we're already checking the spec. Task-number: QTBUG-75585 Change-Id: Ib6d824569aba8def2f1319ef3a11cca6869a5b5e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add unit test to check emoji handling in date-time parsingAndreas Buhr2020-09-233-0/+17
| | | | | | | | Add some unit tests using emojis as separator characters to check utf handling. Change-Id: I03c4bb5cd349e649c58e8a908c38a0185d80e722 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* CMake: Regenerate projects to use new qt_internal_ APIAlexandru Croitor2020-09-235-8/+8
| | | | | | | | | | | Modify special case locations to use the new API as well. Clean up some stale .prev files that are not needed anymore. Clean up some project files that are not used anymore. Task-number: QTBUG-86815 Change-Id: I9947da921f98686023c6bb053dfcc101851276b5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Use qint64 for value of that type in tst_QDateTime millisecond testsEdward Welbourne2020-09-151-71/+91
| | | | | | | | | | | | The test was previously using int; I shall be wanting to add tests that exercise the bounds of qint64. Clean up the layout of the test-row additions in the process of making a trivial change to them all. Also const the QFETCH() types so we catch any use of non-const methods on the values fetched. Change-Id: I4b0187de71f5f14b39b4eabe8afd12a196f73d23 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Trim trailing 0s from QTime construction, where neither use nor ornamentEdward Welbourne2020-09-151-153/+153
| | | | | | | | The seconds and milliseconds default to 0; so omit them when they're zero, unless there's nearby code that contrasts nicely with them. Change-Id: Iea049015e976f5a5209fe87a2cbfdae9de49a559 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Don't use default-constructed QTime() where QTime(0, 0) is intendedEdward Welbourne2020-09-141-35/+43
| | | | | | | | | | QTime() is invalid. Only the seconds and milliseconds are optional, for valid times. Use startOfDay() for zoned times, QTime(0, 0) for fixed-offset ones. Change-Id: I3b65d5c3733ac83dc3a6c214859c3f56a480bb94 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove some unused private methods and replace anotherEdward Welbourne2020-09-141-90/+90
| | | | | | | | | | | | | Nothing used defDateTime(), nothing but it used defTime(). The only other use of defDate() were from one test, which might as well make it a local variable. QDateTime's default is invalid, making invalidDateTime() redundant, and the invalidDate() and invalidTime() it called had no other users. Change-Id: I0e07ee58478bfe8ba680eafb52e2f73a962edd33 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* [QtCore] Fix QDateTime unit test: time zone of system was usedAndreas Buhr2020-09-111-10/+9
| | | | | | | | | | | | | | | | Test data for QDateTime unit tests was constructed in system's local time, which made unit test outcome dependent on the time zone of the system running the tests. This led to failing unit tests on systems with libc6 version 2.31 or newer. A QDateTime in a timezone, which has daylight saving time, was created and then used in Hawaii's time zone,which has no daylight saving time. Newer glibc checks this and returns errors. This patch changes the behavior to create the test data in a specified time zone setting. Task-number: QTBUG-80441 Change-Id: I0330b647fa011be99141dde09001ff2d58bd3a5f Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* [QtCore] QDateTime: switch from newRow to addRow in unit testsAndreas Buhr2020-09-111-4/+4
| | | | | | | | | Instead of doing string formating first and then using QTest::newRow, we can do both at the same time using QTest::addRow Change-Id: Ia5c90eb705a806e37b96a1fa174a6557f91bee6d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* [QtCore] Adapt QDateTime unit tests to use QByteArrayAndreas Buhr2020-09-111-8/+8
| | | | | | | | | | | To not have to bother with encodings, a few QStrings are changed to QByteArrays. This way, a few calls to QString::fromLatin1 and to QString::toLocal8Bit can be removed Change-Id: Ia0cf27fc2a86f9842ed0f3ebe47b050bb8a3f4e6 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>
* Adapt QDate unit tests to not take into account system localeAndreas Buhr2020-09-101-14/+13
| | | | | | | | | | | | QDate was changed to consistently use the C local in serialization and parsing in git commit 5ba66c5622e9e0da87a5037399b375d7e8cee554. This commit reflects this change in the unit tests. Task-number: QTBUG-80441 Change-Id: Ib21a215ef0e36c9eaa2c161b92c6877a50ae6f06 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Fix failures in tst_qdatetime under non-english localesMarcel Krems2020-09-091-2/+2
| | | | | | | | | QDateTime::toString uses the C locale since 5ba66c5622e9e0da87a5037399b375d7e8cee554 So don't expect locale specific day- and month-names. Task-number: QTBUG-80441 Change-Id: I08f53b6b33ed9e7eaaa58df4ca6a966c4ba9ef24 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Fix crash on serializing default-constructed QTimeZoneEdward Welbourne2020-08-231-0/+28
| | | | | | | | | | | | | | The serialization code neglected to check against null. Sinze zones are saved either by IANA ID or in our special OffsetFromUtc format, representing an invalid zone by a string that cannot possibly be a valid IANA ID will do. Fixes: QTBUG-86019 Pick-to: 5.15 Pick-to: 5.12 Change-Id: I6882026403d00f8b254aab34c645f1cf8f9fcc2d Reviewed-by: Taylor Braun-Jones <taylor@braun-jones.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Sort out the overflow cases in tst_QDateTimeEdward Welbourne2020-08-111-13/+12
| | | | | | | | | Use the actual minimum value, rather than minus the maximum, and adapt the overflow expectations so that they're correct west of Greenwich as well as east. Change-Id: I7a5f4510db0fdea3855b5b2bd4c4a86882030efd Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix handling of last second in 1969Edward Welbourne2020-08-111-0/+12
| | | | | | | | Due to a limitation of mktime(), we would have declared it invalid. Tidied up qt_mktime() slightly in the process. Change-Id: I25469e314afee6e0394e564bc69a98883005d4ec Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* CMake: Regenerate tests with new qt_ prefixed APIsAlexandru Croitor2020-07-095-8/+8
| | | | | | | | Use pro2cmake with '--api-version 2' to force regenerate projects to use the new prefixed qt_foo APIs. Change-Id: I055c4837860319e93aaa6b09d646dda4fc2a4069 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Make feature datetimeparser depend on feature datestringEdward Welbourne2020-07-025-30/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | No client of QDateTimeParser actually uses it unless datestring was enabled, nor is it any use without datestring. Various methods conditioned on datestring are broken unless datetimeparser is enabled. We can't condition public API on datetimeparser, as it's a private feature, but client code can condition use of it on the private feature. All string-to-date/time conversions that use a string format (this includes all locale-specific formats) depend on feature datetimeparser. Change #if-ery (or add it) in all client (including test) code to test the right feature. Tidied up some code in the process. Killed some already-redundant textdate #if-ery. Renamed a test whose name claimed it involved locale, which it doesn't, in the course of #if-ing it. This simplifies the condition for feature datetimeedit (which overtly depended on textdate, redundantly since it depends on datestring which depends on textdate; its dependence on datetimeparser now makes its dependency on datestring also redundant). It also removes the need for assorted datestring checks in QDateTimeParser itself. Change-Id: I5dfe3a977042134b2cfb16cbcc795070634e7adf Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Update tests/auto/corelib/time/'s CMake configEdward Welbourne2020-07-025-1/+15
| | | | | | | | | Recent changes in .pro files hadn't been propagated. Re-ran pro2cmake.py and saved the results. Change-Id: I91e4cd513329bce10ce8cbd0ddae8240af050213 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove assortee pre-Qt6 code from date/time testsEdward Welbourne2020-07-023-147/+0
| | | | | | | | Assume QT_VERSION >= QT_VERSION_CHECK(6,0,0) throughout. Change-Id: If70c59f9319f72549de581fc446fd60d32b02521 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Replace a constant with a predicate function using itEdward Welbourne2020-07-011-6/+8
| | | | | | | | | | Rather than naming a "GMT" string so as to repeatedly test whether a date-time's string representation ends in it, use a simple lambda to do the test, so that the string is only used in one place anyway. Makes the test code more readable. Change-Id: I5afad9ad5d58702bea7f24e5e5688ea4d738ae0d Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Use ranged for loops in place of foreach in QTimeZone testsEdward Welbourne2020-06-238-13/+15
| | | | | | | | | This (and use of Q_SLOTS for the test slots) makes it possible to enable QT_NO_KEYWORDS and QT_NO_FOREACH in all the corelib/time/ tests. Change-Id: I85fd358f3d1a72c9269d5260d0224640c1751f2d Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* Remove winrtOliver Wolff2020-06-061-3/+0
| | | | | | | | | Macros and the await helper function from qfunctions_winrt(_p).h are needed in other Qt modules which use UWP APIs on desktop windows. Task-number: QTBUG-84434 Change-Id: Ice09c11436ad151c17bdccd2c7defadd08c13925 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Turn badly-named test into two data rows of another testEdward Welbourne2020-05-291-16/+6
| | | | | | | | | | | | Since ancient times, tst_QDateTime::fromString_LOCALE_ILDATE() has claimed to be Windows-only, although there is nothing MS-specific about it; its name also purports to implicate locale, which it doesn't. Turn it into two data rows for the more general fromStringDateFormat() test, with no extra #if-ery about it. Change-Id: I239c0f80f8f7fa42d498a0f801cc8edfb1db3d8c Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Rework QLocale and QDateTime tests that expect CET abbreviationEdward Welbourne2020-05-281-21/+6
| | | | | | | | | | | | | | | | | | | | | | The name CET is locale-dependent; but QLocale doesn't know about localization of time zone names. Such abbreviated zone names are, in any case, potentially ambiguous - various zones around the world have collisions - so they can't be relied on. QTimeZone's various backends have differing handlings of how to abbreviate zone names (MS's provides no abbreviated names at all); and it appears macOS actually follows the relevant localizations. So it is hopeless to hard-code the expected zone abbreviations. Changed the tests to consult QTimeZone for the abbreviation and compare what it gets with the results of checks which should match this. This is less stringent, but it is at least robustly correct, thereby getting rid of assorted kludges and #if-ery. Pick-to: 5.15 Task-number: QTBUG-70149 Change-Id: I0c565de3fd8b5987c8f5a3f785ebd8f6e941e055 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Make QDateTimeParser recognize local time offsetsAndrei Golubev2020-05-281-1/+39
| | | | | | | Fixes: QTBUG-84209 Pick-to: 5.15 Change-Id: Iedbc7beafcaa55c72fec3ac5a5f519c6ed5f7770 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Teach QDateTimeParser some common time-zone offset formatsAndrei Golubev2020-05-121-2/+129
| | | | | | | | Fixes: QTBUG-83687 Fixes: QTBUG-83844 Pick-to: 5.15 Change-Id: Ia1c827017b93cf8277aa5a0266805d773d2d9818 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Make qtbase compile without QT_CONFIG(timezone)Andrei Golubev2020-05-112-9/+54
| | | | | | | | Fixes: QTBUG-83795 Pick-to: 5.15 Change-Id: I05eaaf57d87a9111d3609ebab81bc707f8af98f0 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Catch overflow in QDateTime::fromSecsSinceEpoch()Edward Welbourne2020-05-081-0/+31
| | | | | | | | | | It's documented to be undefined if the number of seconds is outside the allowed range, but it doesn't hurt for that undefined behavior to happen to be that the result is invalid. Added a simple test. Change-Id: I20c3f680c7948b3904f213452272133be77e4d62 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove all locale-dependence from Q(Date|Time)+Edward Welbourne2020-05-081-10/+0
| | | | | | | | | | | | | | | [ChangeLog][Important Behavior Changes][QDateTime] Removed all locale-dependence from QDate, QTime and QDateTime, including the Qt::DateFormat members that select the formats of the default and system locales and the toString(Qt::DateFormat, QCalendar) overload, which only used its calendar for these formats. All toString() methods now use, and all fromString() methods only recognize, the C locale's names for days and months. Use QLocale's methods if you need to take locale into account. Fixes: QTBUG-80441 Change-Id: I3a8968438741afb00f44262f79659c51e9b06c35 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Move a test of QLocale's methods out of tst_QDateTimeEdward Welbourne2020-05-081-51/+1
| | | | | | | | | | | | It clearly belonged in tst_QDate::toDateTime(), for which it adds a few more test-case and in which it inspires some further testing. The new testing of case-insensitivity doesn't work if the format contains stray non-format characters, so added a new data column to take care of that. Pick-to: 5.15 Change-Id: I73619be02091c97024a84cb963c7029e9fd0569a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Condition some date-time tests on feature textdateEdward Welbourne2020-05-081-8/+18
| | | | | | | | | | They use the Qt::TextDate format, so do depend on the feature. Rename one in the process; nothing in its test has anything to do with de_DE locale. Pick-to: 5.15 Change-Id: I2adae5c46e6009c13b433993ed2c3c761a500bfb Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Purge from Q(Date|Time)+ most things marked to go at Qt 6Edward Welbourne2020-05-053-194/+3
| | | | | | Change-Id: Ib3f48c74132b47649dc7b4cbacf2cefed5a57687 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-04-231-0/+5
|\ | | | | | | Change-Id: Iaa439ba7dff19a17e3716b3d30f49f60fa6e38f8
| * Handle specified time-spec in date-time parsingAndrei Golubev2020-04-221-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a date-time was parsed from a string, the result was equal (as a date-time) to the correct value, but had (at least in some cases) the wrong spec, where it should have had a spec reflecting the zone specifier parsed. The time-spec imposed for the benefit of QDateTimeEdit is now moved from QDateTimeParser to QDateTimeEditPrivate, which takes over responsibility for imposing it. QDateTimeParser assumes Qt::LocalTime in member functions (where applicable) and uses the time-spec parsed from the string when constructing the date-time. QDateTime::fromString() and QLocale::toDateTime() are updated to use the full QDateTime returned by QDateTimeParser. Fixes: QTBUG-83075 Done-With: Edward Welbourne <edward.welbourne@qt.io> Change-Id: I8b79add2c7fc13a200e1252d48dbfa70b36757bf Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* | Make QLocale(QString) explicitLars Knoll2020-04-011-4/+4
| | | | | | | | | | | | | | | | We should not implicitly convert a QString to a QLocale object. It can easily create unwanted side effects. Change-Id: I7bd9b4a4e4512c0e60176ee4d241d172f00fdc32 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* | Purge QRegExp use in QDateTime's rfcDateImpl()Edward Welbourne2020-02-273-20/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace with a parser which actually does the job right, fixing various infelicities in the parsing in the process. Make the parser strict about formatting. Adjusted tests to match. Fixed some QTime invalidity tests to each test only one invalidity at a time (the invalid year and day tests also used an invalid month). [ChangeLog][QtCore][QDateTime] The parser for the Qt::RFC2822Date format is now stricter, requiring the text to exactly match the form of one of the relevant formats. A valid date or time will still be parsed, even if the other part of the content is invalid, as long as it (and any offset, if present) has the right form. In particular, the parser now rejects texts with trailing cruft (other than space). Fixes: QTBUG-80038 Change-Id: Id25675afd75f82f6351f20e79f0154f3ceda35ac Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Merge remote-tracking branch 'origin/wip/cmake' into devAlexandru Croitor2020-02-133-3/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: tests/manual/rhi/hellominimalcrossgfxtriangle/CMakeLists.txt Hopefully final merge from wip/cmake, and then all cmake changes should target dev directly. Change-Id: I29b04c9b0284e97334877c77a32ffdf887dbf95b
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-24 19:40:41 +0000