summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/time
Commit message (Collapse)AuthorAgeFilesLines
* Deprecate locale-related DateFormat enum membersEdward Welbourne2020-01-313-5/+22
| | | | | | | | Qt 6 shall remove all locale-dependence from Q(Date|Time)+. Task-number: QTBUG-80441 Change-Id: Iebaaa2bd776bccfe0d73c15f36cbdd456b71ca59 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Clarify handling of unspecified year in two QCalendar methodsEdward Welbourne2020-01-311-1/+24
| | | | | | | | | | [ChangeLog][QtCore] QCalendar::monthsInYear(QCalendar::Unspecified) now returns maximumMonthsInYear(). QCalendar::daysInYear() now makes clear that its handling of unspecified year is undefined. Change-Id: Ifef8723193868c666f6afeb7f190af4929d30dea Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Deprecate QDateTime(const QDate &) in favor of QDate::startOfDay()Edward Welbourne2020-01-301-3/+3
| | | | | | | | | | | It needed re-implemented in terms of the new API (in case QTime(0, 0) was skipped, on the date in question, by a spring-forwrd), which makes it redundant (and supports choice of spec and zone or offset, which it did not). Change-Id: I1e3c3e794632c234f254be754ed6e4ebdaaaa6bc Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-01-151-22/+17
|\ | | | | | | Change-Id: I8dbcf23835d52d3aa7d018ed250814d60c68aa83
| * Combine negativeYear() and printNegativeYear()Edward Welbourne2020-01-141-22/+17
| | | | | | | | | | | | | | | | | | | | They overlapped and the latter had duplicated code, so make them into a single data-driven test. At the same time, replace the '-' at the start of the expected string with QLocale::negativeSign(), since the test fails otherwise when LC_NUMERIC=nb_NO on Linux (Debian/testing). Change-Id: I051c75abff16b2e6f8278fcb152b6bde14c71f9a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | QTime: fix tests with Qt6Christian Ehrlicher2020-01-031-3/+12
| | | | | | | | | | | | | | | | | | | | In Qt6 there is a behavior change with extra stuff after the seconds - it's no longer allowed and will result in an invalid QTime. This was introduced with bf65c277892f6f322fa689c06d81ba9b1d9a8038 but the autotests were not adjusted for it. Change-Id: Ia78f4f2a8019e46d9d0e8e8b8918a3ab2d4638e2 Reviewed-by: Liang Qi <liang.qi@qt.io>
* | QDateTime: fix tests with Qt6Christian Ehrlicher2020-01-021-0/+8
| | | | | | | | | | | | | | | | | | | | In Qt6 there is a behavior change with extra stuff after the seconds - it's no longer allowed and will result in an invalid QDateTime. This was introduced with bf65c277892f6f322fa689c06d81ba9b1d9a8038 but the autotests were not adjusted for it. Change-Id: Iee6a9a7ac6cbb2754a68e082bb7074d17fac9d9c Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-12-121-0/+38
|\| | | | | | | Change-Id: I69238f23882deebeaad46e4fdcf899ab22cc2b8f
| * Fix more mis-handling of spaces in ISO date format stringsEdward Welbourne2019-12-101-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ISO date format doesn't allow spaces within a date, although 3339 does allow a space to replace the T between date and time. Sixteen tests added to check this all failed. So clean up the handling of spaces in the parsing of ISO date-time strings. [ChangeLog][QtCore][QDateTime] ISO 8601: parsing of dates now requires a punctuator as separator (it previously allowed any non-digit; officially only a dash should be allowed) and parsing of date-times no longer tolerates spaces in the numeric fields: an internal space is only allowed in an ISO 8601 date-time as replacement for the T between date and time. Change-Id: I24d110e71d416ecef74e196d5ee270b59d1bd813 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Liang Qi2019-12-101-14/+51
|\| | | | | | | | | | | | | Conflicts: tests/auto/network/kernel/qnetworkinterface/BLACKLIST Change-Id: I1e8866c63b54bcd95fc2a044276ee15b7f60e79a
| * Allow lower-case for the T and Z in ISO 8601 date formatEdward Welbourne2019-12-061-0/+2
| | | | | | | | | | | | | | | | | | Cite RFC 3339 as basis for allowing a space in place of the T, too. The RFC mentions that ISO 8601 accepts t and z for T and Z, so test for them case-insensitively. Add a test for this. Change-Id: Iba700c8d74d485df154d27300aab7b1958e1ccef Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
| * Fix handling of trailing space at the end of an ISO date-timeEdward Welbourne2019-12-061-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If milliseconds were followed by a space, the space was included in the count of "digits" read as the fractional part; since we read (up to) four digits (so that we round correctly if extras are given), a harmless apce could cause scaling down by too large a power of ten. Since QString::toInt() ignores leading space, we were also allowing interior space at the start of the milliseconds, which we should not, so catch that at the same time. Added tests, including one for the rounding that's the reason for reading the extra digit, when present. Fixes: QTBUG-80445 Change-Id: I606b29a94818a101f45c8b59a0f5d1f78893d78f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
| * Fix crash when a date-time has an invalid time-zoneEdward Welbourne2019-12-061-14/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QDateTime is a friend of QTimeZone, so can access its internals; but it must check the zone is valid before doing so. Expanded tst_QDateTime::invalid() and made it data-driven to catch the failure cases. Commented on a test-case that caught a mistake in my first attempt at this, and on QDateTimeParser's surprising reliance on a quirk of QDateTime::toMSecsSinceEpoch()'s behavior. Fixes: QTBUG-80146 Change-Id: I24856e19ff9bf402152d17d71f83be84e366faad Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Ulf Hermann2019-12-034-44/+140
|\| | | | | | | | | | | | | Conflicts: src/corelib/serialization/qcborvalue.cpp Change-Id: I675a3029955c96e81a33ed9d98b72b55b6784b52
| * Work around macOS's inconsistency in naming of India's time-zoneEdward Welbourne2019-11-281-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | macOS fails to create a zone for the name its own systemTimeZone claims to have (see new comment). So make sure we do consistently recognize the name systemTimeZoneId() returns, using systemTimeZone from which we got its name. Add minimal testing of system time-zone. Fixes: QTBUG-80173 Change-Id: I42f21efbd7c439158fee954d555414bb180e7f8f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
| * Be consistent in the RFC2822Date invalid character testsEdward Welbourne2019-11-273-41/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | The ones we reject used a zero offset while the one that does parse (though it shouldn't - revised comment) has a one hour offset. Made them all use that offset and added a partner test that has no invalid characters, so ensure the success of the invalid character tests isn't due to falsely rejecting the valid date/time text to which the invalid characters are added. Task-number: QTBUG-80038 Change-Id: I6e3dd79b981af6803e60877229c56599cfd719cb Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
| * Permit leading space at start of RFC 2822 Date formatEdward Welbourne2019-11-273-0/+32
| | | | | | | | | | | | | | Relevant RFCs explicitly permit such space. Change-Id: I8eb444e96287368cbbf973c77513b43d1d36f972 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
| * Make Qt::RFC2822Date's doc match up with its implementationEdward Welbourne2019-11-273-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The qdatetime implementation's rfcDateImpl() uses regexes which did not match its comments; nor did either the regexes or the comments match what was documented. A review of relevant RFCs suggests we should revise this in future, probably at Qt 6. The documentation also only addressed the formats recognized when parsing a date-time, without indicating how they are serialised or how dates and times are handled separately. Added a note to the tests for the read-only formats, to remind the reader that the RFCs merely recommend recognising these - be permissive in what you expect and strict in what you deliver. Change-Id: I0f0bec752e7a50bde98cceceb7e0d11be15c6a6f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-11-152-6/+42
|\| | | | | | | | | | | | | | | Conflicts: src/gui/rhi/qshader.cpp tests/auto/corelib/time/qtimezone/tst_qtimezone.cpp Change-Id: I1c4ae718eb3592a0a0a90af9d11553f3ab68cad5
| * Allow longer time-zone components on AndroidEdward Welbourne2019-11-142-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Android uses its own time-zone naming, which includes a zone called "Canada/East-Saskatchewan", whose second component is 17 characters long. This violates a rule in the IANA naming scheme for zones, that limits components to 14 characters each. So tweak the isValidId() check to allow Android its long names. Android has added Outer Mongolian time-zones, which are as borked as many others in 1970, so blacklist those transitionEachZone() tests. Fixes: QTBUG-69128 Change-Id: I46f674f095431335b16900860d83b624257ae3bb Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
| * Move some tests of QTimeZonePrivate::isValidId() to where they belongEdward Welbourne2019-11-131-28/+24
| | | | | | | | | | | | | | | | | | | | | | They were tucked away in the back-end of the isTimeZoneIdAvailable() test, but a separate isValidId() test had been added more recently, which made some (arguably all) of them redundant. Reworked this test in the process, so that the QSKIP() happens in _data() once instead of in the test that's never run because there are no data rows. Change-Id: Icaa6227ace9a1aa944d085691cdcfb3adf4a51dc Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-10-131-22/+20
|\| | | | | | | Change-Id: I9953c1ca16862184c2373027e946c482ce8e6f0e
| * Distinguish invalid datetimes from othersEdward Welbourne2019-10-111-22/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A default-constructed QDateTime is invalid, but compared equal to a valid one referencing the start of 1970. This lead to date properties in QML being initialized invalid but not getting an onChange if the first value they're set to is the start of 1970. Fixing that then lead to some tests failing. Indeed, the original equality check involved using toMSecsSinceEpoch(), whose value is undefined unless the datetime is valid, without a prior check on its validity: so ensure all uses of toMSecsSinceEpoch() are guarded with isValid() checks. Reworked tst_QDateTime::toSecsSinceEpoch() to use its bool column (previously unused, after separating from toTime_t(), which uses this column for "out of time_t's range") for validity of the datetime. [ChangeLog][QtCore][QDateTime] Invalid datetimes are now treated as equal and less than all valid ones. They could previously be found equal to valid datetimes. Fixes: QTBUG-79006 Change-Id: Ie72deb8af4350a5e808144d0f6e42dc8eb3ff5ef Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-10-011-3/+3
|\| | | | | | | Change-Id: I77ba01f09b3dbcaf13cb265a70d9da661c32a61f
| * Merge remote-tracking branch 'origin/5.13' into 5.14Liang Qi2019-09-301-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/global/qrandom.cpp src/corelib/io/qfileinfo.cpp src/corelib/kernel/qeventdispatcher_win.cpp src/corelib/kernel/qeventdispatcher_win_p.h src/gui/text/qfontdatabase.cpp src/platformsupport/fontdatabases/mac/qcoretextfontdatabase.mm src/plugins/platforms/windows/qwindowsglcontext.cpp src/testlib/qtestcase.cpp Done-With: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-With: Edward Welbourne <edward.welbourne@qt.io> Change-Id: I4893212471aa24be804c989a581810e2f714545c
* | Add support for UTC[+-]\d+(:\d+){,2} time zone IDsEdward Welbourne2019-09-161-4/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We presently only support the UTC-based offset timezones that are listed in the CLDR; and it doesn't make sense to list more than these in the list of available zones. However, if someone sets their TZ environment variable to a conformant UTC-offset string, we should make sense of it even if CLDR doesn't mention it. Only do so as final fall-back, as backends may handle the givne name better (some such IDs appear in the windows-compatibility list, for example). Added tests for the new UTC-offset time-zone names. Removed one test that relied on them not being supported. [ChangeLog][QtCore][QTimeZone] The constructor can now handle general UTC-offset zone names. The reported id() of such a zone shall be in canonical form, so might not match the ID passed to the constructor. Fixes: QTBUG-77738 Change-Id: I9a0aa68281a345c4717915c8a8fbc2978490d0aa Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Move some time-zone validity tests to where they belongEdward Welbourne2019-09-161-27/+27
|/ | | | | | | | | | | | In tst_QTimeZone::isTimeZoneIdAvailable(), a block of tests of QTimeZonePrivate::isValidId() overlapped with what tst_QTimeZone::isValidId_data() tests; so move out of the former and adapt to use by the latter. At the same time, check that each allegedly available zone *is* available enough that we can create it and it's valid. Change-Id: I3f7c8e2e3fbfb201747c7b769d691d7f17fc6b2a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* MS TZ data: avoid calculating a date in year 0Edward Welbourne2019-09-131-0/+8
| | | | | | | | | | | | | | | | | | | | | | There is no year 0 in the proleptic Gregorian calendar, so QDate() won't be happy if asked for a date in it. Tweak scanning of the data we get from MS-Win so as to avoid a date calculation that could otherwise happen in year 0 when constructing QDateTime(QDate(1, 1, 1), QTime(0, 0, 0), QTimeZone("Australia/Sydney")). Added a test for this case, which Oliver Wolff has kindly verified does reproduce the assertion failure. However, Coin is unable to reproduce, as all its MS builds are configured with -release, so Q_ASSERT() does nothing. (The relevant code then skips over year 0, albeit for the wrong reasons, and gets the right results, albeit inefficiently, leaving no other symptom by which to detect the problem.) Fixes: QTBUG-78051 Change-Id: Ife8a7470e5bd450bc421e89b3f1e1211756fc889 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Rename calendar methods from m{in,ax} to m{in,ax}imumEdward Welbourne2019-09-041-2/+2
| | | | | | | | | Words should not be abbreviated. Split a long line and reflowed some comments in the process. Fixes: QTBUG-78008 Change-Id: I52d75409f02e2cecbed3e94d424617ad594c275b Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Add support for the Islamic Civil calendarSoroush Rabiei2019-08-221-0/+4
| | | | | | | | | | | | | | | | This has its own locale data, extracted from CLDR. This data may potentially be shared with other variants on the Islamic calendar, so is handled by a separate base-class, QHijriCalendar, on which such variants may base their implementations. [ChangeLog][QtCore][QCalendar] Added support for the Islamic Civil calendar, controlled by feature islamiccivilcalendar, with locale data that can be shared with other implementations, controlled by feature hijricalendar. Fixes: QTBUG-56675 Change-Id: Idf32d3da7034baa8ec5e66ef847e59a8a2f31cbd Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add support for the Jalali (Solar Hijri or Persian) calendarSoroush Rabiei2019-08-211-0/+5
| | | | | | | | | | | | This has its own locale data, extracted from CLDR. [ChangeLog][QtCore][QCalendar] Added support for the Jalali (Persian or Solar Hijri) calendar, controlled by feature jalalicalendar. Fixes: QTBUG-58404 Change-Id: Id5c56a10db05a4fd612aafc01615273db81ec743 Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add support for Julian and Milankovic calendarsSoroush Rabiei2019-08-211-0/+8
| | | | | | | | | | | | | These share their locale data with the Gregorian calendar, making them virtually free to add. Still leave them out of the boot-strap build, though. [ChangeLog][QtCore][QCalendar] Added support for Julian and Milankovic calendars. These are enabled by default, except in bootstrap builds. Change-Id: I585045ed9e78c1e959957f6772b3e144093b701c Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add support for calendars beside GregorianSoroush Rabiei2019-08-203-0/+225
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add QCalendarBackend as a base class for calendar implementations and QCalendar as a facade via which to access it. QDate's implicit implementation of the Gregorian calendar becomes QGregorianCalendar and QDate methods now support choice of calendar. Convert QLocale's CLDR data for month names to a locale-data component of each supported calendar and relevant QLocale methods now support choice of calendar. Adapt Python scripts for locale data generation to extract month name data from CLDR (keeping on version v35.1) into the new calendar-locale files. The locale data for the Gregorian calendar is held in a Roman calendar base, for sharing with other calendars. Add tests for basic uses of the new API. [ChangeLog][QtCore][QCalendar] Added QCalendar to support diverse calendars, supported by implementing QCalendarBackend. [ChangeLog][QtCore][QDate] Allow choice of calendar in various operations, with Gregorian remaining the default. Done-with: Lars Knoll <lars.knoll@qt.io> Done-with: Edward Welbourne <edward.welbourne@qt.io> Fixes: QTBUG-17110 Fixes: QTBUG-950 Change-Id: I9d6278f394269a183aee8156e990cec4d5198ab8 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* unblacklist passing testsDaniel Smith2019-07-081-2/+0
| | | | | | | | These tests have not failed on the removed platforms for at least 60 days Task-number: QTBUG-76608 Change-Id: If7a9f4db907124e3cd54e3f4b0ad3e20717d1912 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove usages of deprecated APIs from QDateTimeSona Kurazyan2019-07-022-5/+35
| | | | | | | | | | | | | | | | | | - Replaced the usages of: * QDateTime::toTime_t() -> QDateTime::toSecsSinceEpoch(). * QDateTime::fromTime_t() -> QDateTime::fromSecsSinceEpoch(). * QDate::shortDayName() -> QLocale::system().dayName(). * QTime by QElapsedTimer, where the deprecated methods of QTime were used. - Modified the tests for the deprecated methods to be enabled only when the corresponding methods are enabled: when the deprecated APIs are disabled, the tests will be also disabled, and the compilation won't be broken. Task-number: QTBUG-76491 Change-Id: I4d565db2329e580c567aae511696eb1efe120843 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Move YearRange to QDateTime from its PrivateEdward Welbourne2019-07-011-0/+10
| | | | | | | | | | | | | | | | | As planned when adding YearRange: now that it's merged up to dev, move it to QDateTime, since we can add to the API at 5.14.0. This follows up on commit 82ad4be4a2e0c2bccb6cd8ea2440aefee4ec48ec. Change-Id: I81b6c2331121a71e2592514781c02c5756e70c52 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Merge remote-tracking branch 'origin/5.13' into devLiang Qi2019-06-271-2/+5
| | | | | | | | | Conflicts: .qmake.conf src/network/ssl/qsslsocket_openssl.cpp Done-With: Timur Pocheptsov <timur.pocheptsov@qt.io> Change-Id: Ibb57a0548b4977797b400637487a56245ac1c024
* Separate out the time, zone, date code from corelib/tools/Edward Welbourne2019-06-0616-0/+7665
We'll be adding calendar code here as well, and tools/ was getting rather crowded, so it looks like time to move out a reasonably coherent sub-bundle of it all. Change-Id: I7e8030f38c31aa307f519dd918a43fc44baa6aa1 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-17 18:32:17 +0000