summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/time
Commit message (Collapse)AuthorAgeFilesLines
* Make POSIX transition rule parser more robustEdward Welbourne2021-04-141-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | The POSIX rule parser used by QTzTimeZonePrivate recklessly assumed that, if splitting the rule on a dot produced more than one part, it necessarily produced at least three. That's true for well-formed POSIX rules, but we should catch the case of malformed rules. Likewise, when calculating the dates of transitions, splitting the date rule on dots might produce too few fragments; and the fragments might not parse as valid numbers, or might be out of range for their respective fields in a date. Check all these cases, too. Added a test that crashed previously. Changed QTimeZone::offsetFromUtc() so that its "return zero on invalid" applies also to the case where the backend returns invalid, in support of this. Fixes: QTBUG-92808 Change-Id: Ica383a7a987465483341bdef8dcfd42edb6b43d6 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Robert Löhning <robert.loehning@qt.io> (cherry picked from commit 964f91fd25a59654905c5a68d3cbccedab9ebb5a) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Rework tst_QDateTime::toString_isoDate() to eliminate an XFAILEdward Welbourne2021-02-161-16/+17
| | | | | | | | | | | | | | | | Instead of an XFAIL, actually test what we expect will happen for the test, namely that the milliseconds will be lost. In the process, verify that milliseconds since epoch also matches what was expected, change an "expecting empty" condition to check for the "invalid" test-case to which it's actually relevant and note that this test-case shall need amended when we update our ISODate support to the 2019 update, which extends the year range. Task-number: QTBUG-56552 Change-Id: I680aa31ee0dcc8fadabb5d4cd6c083a8afd48573 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit cc93dadf772480df3b27fd031a471047a5db0038) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix tst_QDateTime::systemTimeZoneChange() for 32-bit systemsEdward Welbourne2021-02-151-14/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test verified that a LocalTime's time since Epoch changes when the system time-zone changes. This works when the QDateTime object is in short form and recomputes its offset from UTC every time it is needed, but fails with a pimpled QDateTime, as this caches its offset from UTC when it is created, saving the recomputation which - in the far more usual case where the system time-zone does not change in the lifetime of a QDateTime object - would normally produce the same result. Changed the test to use a newly-created QDateTime constructed with the same parameters, which doesn't have the cached out-of-date knowledge of its zone offset. Removed the XFAIL. Made the test data-driven and added test-cases: one so close to the Epoch that it should be short even on 32-bit systems, one so far that it's pimpled even on 64-bit systems (used in reproducing the issue in order to debug it). This then revealed that Android 5 doesn't seem to support the POSIX zone IDs used by this test, so it now verifies that LocalTime has the expected offset from UTC after zone changes, QSKIP()ping if not. Documented that the behavior of LocalTime is undefined after a change to the system time-zone. Cleaned up the existing doc of Qt::TimeSpec in the process. Fixes: QTBUG-89889 Change-Id: I1058f47a1ff3ee1c326f3579ac80bd8bab242e28 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 02ae1b522193b60e7a5c8e5eff7a15d25b0f7aae)
* Correct string comparison in Android's IANA ID matching codeEdward Welbourne2021-02-022-31/+11
| | | | | | | | | | | | | | | | | | | | | | It used QString.compare() and assumed it was returning a bool true on equality, when it actually returns an int that compares to 0 as the given strings compare. So it should use compare() == 0. This fixes several of QTimeZone's blacklisted tests on Android and a crasher, which we dodged with a QSKIP. Added an id-comparison to a test. Gave two local variables more informative names, made an early return into a QSKIP so it explains itself. Fixes: QTBUG-89905 Fixes: QTBUG-69122 Fixes: QTBUG-69132 Fixes: QTBUG-87435 Change-Id: Icf18ed5a810143d6e65d36e34a70e82faac10b8e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> (cherry picked from commit 6ee13db700eecd8dfed54a9ec2d1081b39511562) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix handling of Sunday in POSIX time-zone rulesEdward Welbourne2021-02-011-11/+18
| | | | | | | | | | | | | | | | | | | | | | Dating from the origins of our support for the zoneinfo file format, the mapping of POSIX's day-numbering (0 = Sunday through 6 = Saturday, see [*]) to Qt's (1 = Monday through 7 = Sunday) was done by mapping 0 to 1, when it should have been 7. [*] http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html Corrected a QTimeZone test that trusted the results it got without checking which day of the week those were: they were all Mondays. Verified that the corrected dates are in fact Sundays. Checked the zone abbreviations, too. Fixes: QTBUG-90553 Change-Id: I84b4b14f9892ff687918cd3c42c7c9807e45313c 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> (cherry picked from commit 38a72af4fd311219779f89b2b78cd56d879f61db) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix problems with offset-derived ids for QTimeZoneEdward Welbourne2021-01-192-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When creating a time-zone from a UTC+offset name that isn't known to the system, QTimeZone (since the fix to QTBUG-77738 in 5.15.0) falls back to constructing a suitable UTC-offset backend; however, the id of this is not guaranteed to match the id passed in to the constructor. In all other cases, the id of a QTimeZone does match the id passed to its constructor. Some utcOffsetId testcases had different id() than the id passed to the constructor, due to mismatches where a zone was constructed using the fall-back but the generated id included its minutes (as :00) or omitted its seconds. The omission of seconds is clearly a bug, but we also don't want to include :00 for seconds when it's not needed. So change QTimeZonePrivate::isoOffsetFormat() to accept a QTimeZone::NameType to configure how much we include in an id. Its callers other than the relevant constructor (from offset) still get minutes, even when :00, but will also get seconds added if that isn't zero; and the constructor from offset now gets the short form obtained by omitting all trailing zeros. Since all valid whole-hour offset names that do include :00 for the minutes field are in fact known standard offset names, the elision of minutes will only affect zones created by ID in the case of a whole-hour offset given without :00 minutes specifier, so these shall necessarily in fact get the ID passed to the constructor. Creating by UTC-offset with a name that specifies zero seconds will result in a QTimeZone instance whose id() differs from what was passed to its constructor (eliding the :00 seconds and potentially also minutes, if also zero) but this should be the only case where a QTimeZone's id doesn't match the one passed to the constructor, when constructed by id. Fixed inconsistency between the offset-constructor's declaration (taking offset as int) and definition (taking qint32) in the process. Added an id check to the utcOffsetId() testcase. Amended two tests of offset-derived time-zones' IDs, added comments to make clear how one of those differs from a matching standard name test and converted two uses of QCOMPARE(, true) to QVERIFY(). [ChangeLog][QtCore][QTimeZone] QTimeZone instances created by offset from UTC (in seconds) shall now only include minutes in their ID when the offset is not a whole number of hours. They shall also include the seconds in their ID when the offset is not a whole number of minutes. Task-number: QTBUG-87435 Change-Id: I610e0a78e2aca51e12bfe003497434a998e93dc7 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 50c63446f525a8625b6315597cb0897d89908d6b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Add test creating QDateTime in double-DST gap in 1947 GermanyAndreas Buhr2020-12-241-0/+9
| | | | | | | | | | | | In 1947, Germany had not only a summer time but also a "Hochsommerzeit", a high summer time. This patch adds a test creating a QDateTime in the time gap at the beginning of this Hochsommerzeit on May 11, 1947. Change-Id: Ib81a23914965f092c3e3195e4c7258e5a4e0b30e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 741862875c4bd72ba6d28cf53f6f88579602e4bf) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Restore previous QDateTime behavior in DST gapAndreas Buhr2020-12-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Historic QDateTime behavior when being asked to create a QDateTime in the DST gap was to interpret the given date as if it was in the time before that gap, mapping it to a point in time after the gap. This has changed with a04411119ead3d4473e4f0ac4bceedc585977b2f . Since then, the given date is interpreted as if it was in the time after the gap, thus being mapped to a point in time before the gap. This patch restores the historic behavior. This was not caught by Coin because machines ran in timezone "Atlantic/Reykjavik" which does not have DST since 1967. This patch changes tests to always run in "Europe/Oslo". Driveby: Test function "findSpring" did some operations in local time, even though being asked to work in a specific time zone. Fixed that. Fixes: QTBUG-86960 Fixes: QTBUG-89208 Change-Id: Iecce5898bf9711a10e7dfc0a25e4bbeaed1c8ade Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 3d785249ba43cf4bd895ed679bac2791e0130dc5) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Regenerate projects using pro2cmake one last timeAlexandru Croitor2020-12-101-0/+2
| | | | | | | | | | And fix up some wrong qmake project files Change-Id: I66cb82aeb9c1419a74df1a650fa78a511ade7443 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 2304acab5ff3bd3832c2e388cfdab27f2a95caa8) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Add unit test for YearMonthDateAndreas Buhr2020-11-201-0/+31
| | | | | | | | | | Coverage analysis showed that QCalendar::YearMonthDate was not rigorously tested. This patch adds a unit test. Change-Id: I0af485d13c4883764b61ea1e35455905cc77b966 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io> (cherry picked from commit b02147788b4013a698955aeea9fa92bb5613cc4d) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Android: blacklist a list of failing tests for androidAssam Boudjelthia2020-11-043-0/+21
| | | | | | | | | | | | | | | | We want to re-enable Android tests in QTQAINFRA-3867. However, many tests are failing already preventing that from happening. QTBUG-87025 is currently keeping track (links) to all of those failing tests. The current proposal is to hide those failing tests, and enable Android test running in COIN for other tests. After, that try to fix them one by one, and at the same time we can make sure no more failing tests go unnoticed. Task-number: QTBUG-87025 Change-Id: Ic1fe9fdd167cbcfd99efce9a09c69c344a36bbe4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Adapt QDate::fromString() to accept negative year numbersAndreas Buhr2020-10-303-1/+104
| | | | | | | | | | | | | The documentation states that QDate::fromString() accepts negative year numbers, but it did not. This patch adds support for negative year numbers to QDate::fromString() and corresponding unit tests. Furthermore, tests are added for positive signs (+) in date strings. Fixes: QTBUG-84334 Task-number: QTBUG-84349 Change-Id: I575291e7b8317055d4bb530011d7b10c9cd37ae1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Add unit tests for QDateTimeParser internalsAndreas Buhr2020-10-301-0/+78
| | | | | | | | | | | | | | | | | | | | So far, the internals of QDateTimeParser and especially the handling of 'Intermediate' values were only tested implicitly by tst_qdatetimeedit. 'Intermediate' values are values which are not valid according to the specified format, but could become valid by adding more characters. This patch adds unit tests which tests parsing of these intermediate values directly. These tests will help implement handling of negative year numbers, where additional complications arise because of possible ambiguities between the minus sign '-' and the separator '-'. Task-number: QTBUG-84334 Change-Id: Ia6ba08df198288b8b11d3b2d2052c194f04fe8a1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-07 17:13:08 +0000