summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/time
Commit message (Collapse)AuthorAgeFilesLines
* Fix duplicate data tag tst_QDate::fromStringFormat:year-match-1999Edward Welbourne6 days1-1/+1
| | | | | | | | | | | | | | There were two of it. The "year-match-*" tests have two year fields, one four-digit the other two-digit, and deal with whether they match. The second year-match-1999 had, however, only a "yy" year format; it in fact belongs to the "just-yy-*" family that follows. So rename it. Amends commit 5108192f67042656afdb3508f8cc2563167fae97 which landed in 6.7. Pick-to: 6.7 Task-number: QTBUG-107185 Change-Id: Ibfe0c33cb00dc068d0f670d27c43ec4dc4550c05 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* More consistent handling of feature timezoneEdward Welbourne6 days2-5/+3
| | | | | | | | | | | | | | Follow-up to commit ae6186c7e8cfdb9420b9119f5affbba7d069598d * require the feature in headers that should only be seen when it's enabled, * expose the auto-test to being run even when the feature is disabled (the parts of that depend on the feature have needed #if-ery) and * fix the Darwin-specific test's misguided #if-ery. Pick-to: 6.7 6.5 Task-number: QTBUG-108199 Change-Id: I398cf44c33ffdcb4bb04f54a9d8ccfef68741e4e Reviewed-by: Mate Barany <mate.barany@qt.io>
* Fix end-of-parse fixup of two-digit year in QDateTimeParserEdward Welbourne6 days1-0/+3
| | | | | | | | | | | | | | | | | When a date string contains day of the week, day of the month, month and two-digit year, it was still possible to get a conflicting result in the default century instead of a consistent result in the next (in fact present) century. The actual logic needed to get the right year has to take into account all date fields. This is all worked out already in actualDate(), so delegate to it instead of trying to make do with just the year info. Pick-to: 6.7 6.6 6.5 Fixes: QTBUG-123579 Change-Id: Id057128d8a0af9f3a7708d0ee173f854bb1a2a8e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
* QIcuTimeZonePrivate constructor: save iteration over all zone IDsNicolas Fella2024-02-081-1/+3
| | | | | | | | | | | | | | | | | | | | ICU returns a "valid" representation of GMT when given an unrecognised ID, so QTZ's constructor has been checking the ID is available before passing it to the backend constructor. That availability check was done by generating the list of available IDs to see if the given ID was in it; this is very inefficient. Furthermore, the QTZ constructor was also checking availability, to work round the same issue in only this one backend, making the check redundant. So overide isTimeZoneIdAvailable() in the ICU backend, calling ucal_getCanonicalTimeZoneID(), which answers the question directly; and drop the duplicate check in the QTZ constructor. Expand a test to verify an invalid name is rejected. Fixes: QTBUG-121807 Pick-to: 6.7 6.6 6.5 Change-Id: I34f996b607b958d12607a94eb273bb1b406cca1a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Rework tst_QTimeZone::windowsId() to use initializer-listsEdward Welbourne2024-02-051-40/+48
| | | | | | | | Instead of clearing a list repeatedly to then repopulate it by appending entries. Change-Id: I82594d69c1cb145defff43d84f92f8410d8997aa Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Change license for tests filesLucie Gérard2024-02-048-8/+8
| | | | | | | | | | | | According to QUIP-18 [1], all tests file should be LicenseRef-Qt-Commercial OR GPL-3.0-only [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: I9657df5d660820e56c96d511ea49d321c54682e8 Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
* Introduce macros to simplify testing comparisonIvan Solovev2024-01-194-51/+33
| | | | | | | | | | | | | | | | | | | | | The problem with the QTestPrivate::testAllComparisonOperators() and QTestPrivate::testEqualityOperators() functions is that if they fail, they point into the helper function, but not into the actual test that called the helper function. This is specially annoying when some test calls the helper function multiple times. This patch introduces the helper macros QT_TEST_ALL_COMPARISON_OPS and QT_TEST_EQUALITY_OPS that wrap the respective function calls together with the QTest::currentTestFailed() check. If the test has failed, the macro generates a meaningful debug message with the original file name and line number. This patch also applies the new macros to qtbase. Task-number: QTBUG-119433 Pick-to: 6.7 Change-Id: Iad709de45e5bf53c82e7afa8e9f51e9275c1e619 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Give the caller control over the century used for two-digit datesEdward Welbourne2023-12-082-7/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The twentieth century is now some way behind us, so using its years when parsing a date-time format that only provides the last two digits is increasingly likely to produce unwelcome results. Most such formats are saved by the "redundant" presence of a day-of-week field but, for those that are not (notably including ASN.1 date fields), there is a need to provide some way to over-ride the twentieth century default. Allow the caller to pass a base year to the fromString() methods, of QDate and QDateTime, and to QLocale's toDate() and toDateTime(), that indicates the first of 100 consecutive years, among which the two digits given can select a year. Add some test-cases to exercise the new API. [ChangeLog][QtCore][QDate] When fromString() has only a two-digit year to go on, it is now possible to set the start-year of the century within which this selects. [ChangeLog][QtCore][QDateTime] When fromString() has only a two-digit year to go on, it is now possible to set the start-year of the century within which this selects. [ChangeLog][QtCore][QLocale] When toDate() or toDateTime() has only a two-digit year to go on, it is now possible to set the start-year of the century within which this selects. Fixes: QTBUG-46843 Change-Id: Ieb312ee9e0b80557a15edcb0e6d75a57b10d7a62 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Add QCalendar::matchCenturyToWeekday()Edward Welbourne2023-12-081-1/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This takes a YearMonthDay and a day-of-the-week, returning a QDate that (if possible, else invalid) has the given day of the week and differs from the YearMonthDay only in the century. This is useful when resolving dates with only two-digit year information, which can be disambiguated by the day of the week. Added tests of the new API. This adds a new virtual method to QCalendarBackend, for which that base class does provide a brute force implementation, so derived classes do not need to add implementations. It is, however, a binary-incompatible change for any backend plugins that may be in use to implement custom calendars. Worked out the details for the Gregorian calendar to make it possible to compute the right century (and whether any century works) without trial-and-error searching. Coded that up as its implementation of the new method. [ChangeLog][QtCore][QCalendar] Added a matchCenturyToWeekday() method for use when resolving dates given day, month and last two digits of the year, along with day of the week. Any custom calendar backend plugins shall need a recompile and may, optionally, implement the new virtual method behind this. Change-Id: I6003c8d9423d6bfb833957bb5120f2d423219c7a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QTimeZone: use new comparison helper macrosIvan Solovev2023-11-282-7/+30
| | | | | | | | | | | | | The class had operator==() and operator!=() defined as public member functions, so use QT_CORE_REMOVED_SINCE and removed_api.cpp to get rid of these methods and replace them with hidden friends. Extend unit-tests by using the helper functions from QTestPrivate. Task-number: QTBUG-104111 Change-Id: Ib9ca613005e2f1521dea5e3cd9e2baa0b47fede4 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Clean up QDate(Time)?::fromString() test-data tables, adding a columnEdward Welbourne2023-11-282-285/+278
| | | | | | | | | | | | | | | | | The new column is currently unused, added for the benefit of an imminent change, but adding its value was going to change every data row, making the new rows with a different value there hard to see amid the diff. So add the unused value to the existing data rows and clean them up in the process: * Use modern string literals * Split lines (that need it) in a consistent way * Give test-cases not-entirely-meaningless names. Change-Id: I9abdd24b7bb945796878c664d2ed82ca6c409fc1 Reviewed-by: Isak Fyksen <isak.fyksen@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Rename Q*Ordering to Qt::*_orderingMarc Mutz2023-11-213-47/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we cannot re-use the pre-existing QPartialOrdering type due to binary-compatibility issues (it's not BC to std::partial_ordering), we're no longer bound to copy its API for consistency. So copy std::*_ordering type API for consistency instead, to ease porting for users that can already use C++20 and everyone else come Qt 7. This patch is another step in that direction, renaming classes and their memmbers to std-compatible names. QPartialOrdering cannot change, as it's pre-existing. So add a completely new type Qt::partial_ordering. Adding conversions from QPartialOrdering is left for a follow-up patch. As a drive-by, change `\c Less` to `\l Less` in the \class documentation blocks of the new classes. Amending c6fe64b17c87ec985f17389bf08eee46606862d4, which didn't have a ChangeLog: [ChangeLog][QtCore] Added Qt::{partial,weak,strong}_ordering as drop-in C++17 stand-ins for C++20's std::{partial,weak,strong}_ordering. Task-number: QTBUG-119108 Change-Id: Ib1296de6b708571a6abca8843ba36c114f6fd34f Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* TestLib: provide helper functions to test relational operatorsIvan Solovev2023-11-136-291/+208
| | | | | | | | | | | | | | | | | | The patch provides two sets of functions: * functions to perform compile-time check for all cv-ref combinations * functions that actually verify the comparison results for all cv-ref combinations. For now it does not test operator<=>(), even if compiled with C++20, because Qt types do not yet implement it. The patch uses the new helper functions to improve testing of date and time classes, because they already provide a full set of relational operators. Change-Id: I8bd869c489543719ea856d6609cac53cbd4dc122 Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QTimeZone(qint32 offsetSeconds): use IANA ID when one is availableEdward Welbourne2023-11-032-3/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | Principle of least surprise: prefer IANA IDs over synthesized ones. This also aligns what id() returns more nearly with what availableTimeZoneIds() reports. Amend some tests to match the new behavior, extend one test to verify id-round-tripping (also for the IANA zones) and another to verify single-digit offset IDs get zero-padded. Document the complications in how id() relates to what is passed to the constructor. (It was already complicated; the present change just aligns it better with IANA IDs, where possible.) Mention, in availableTimeZoneIds(), that (and why) it only includes IANA's offset IDs. Drive-by: fix a typo in another availableTimeZoneIds() overload's doc. [ChangeLog][QtCore][QTimeZone] When created from (only) a UTC offset, or from (only) a non-IANA UTC-offset ID, a QTimeZone instance now uses an IANA UTC-offset ID, where one is available with a matching offset. Previously it used a synthesized UTC±hh[:mm[:ss]] one which would omit trailing :00 for minutes or seconds, which the IANA ID may well include. Task-number: QTBUG-118586 Change-Id: Ifc4976f36361c830c88a8bef0e8b963fe5a2ab43 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QDate: make conversion from/to chrono types constexpr and noexceptIvan Solovev2023-10-301-0/+32
| | | | | | | | | | | | | | | | | Add method stdSysDaysToJulianDay(), which implements the conversion from std::chrono::sys_days to Julian Day in a constexpr and noexcept manner. Use it in the fromStdSysDays() method instead of addDays(), and also in all constructors from std::chrono types. This allows all constructors to be constexpr and noexcept. Simplify toStdSysDays() so that it could also be constexpr and noexcept. Add compile-time roundtrip tests between QDate and std::chrono types. Fixes: QTBUG-118221 Change-Id: Id35a669430162f1932ad8d28b553af2fd7f5c6de Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Report as available every QTimeZone(qint32).id() resultEdward Welbourne2023-10-301-0/+6
| | | | | | | | | | | | | | | | | | | | | | The QTimeZone(id) constructor accepts these IDs, but isTimeZoneIdAvailable() did not admit to this. Although we cannot sensibly list all 183,047 of them in availableTimeZoneIds(), we should not claim they are unavailable. The custom QTZ constructor needs to know when the ID it's been given is an IANA one (to refuse to use it), so it has to be able ask the backends for "is this IANA", so the UTC backend still has to report these IDs as invalid, leaving the QDT frontend to include the check for these offset zones. Extend isTimeZoneIdAvailable() test to include every offset-zone's ID within QTZ's recognized range of offsets. Although the actual range accepted by offsetFromUtcString() is wider, bounded by ±24:59:59, the constructor from offset seconds (rather than offset string) is bounded by ±16 hours. Pick-to: 6.6 6.5 Fixes: QTBUG-118586 Change-Id: Id9b378aee122ec841635584367022fcb47041fdd Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use localized time-zone abbreviations or offsetEdward Welbourne2023-10-271-9/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The actual formatting of date-time strings is handled by the calendar backend, but the code's in qlocale.cpp as it uses some of its tools. When feature timezone is unavailable, we're stuck (as before) with using QDateTime::timeZoneAbbreviation(), but when it's available we can use QTimeZone::displayName() to get the localized form of the abbreviation and offset string. Make matching changes in QDTP so that it recognizes these localized abbreviations. We now have another candidate for what local time might be called, to add to those that must be checked. This naturally implied some changes to tests. It turns out ICU believes en_US uses GMT+1/GMT+2 for CET/CEST. Replace some MS QEXPECT_FAIL()s by including the non-abbreviations we do in fact use on MS in the lists of "abbreviations" to accept. [ChangeLog][QtCore][QLocale] When a datetime format includes the timezone (or offset), the appropriately localised form is (to the extent the timezone backend in use supports this) used where, previously, a haphazard choice of system and C locale was used. This applies to both serialization and parsing. Task-number: QTBUG-115158 Change-Id: I04f9c1055c3b9008320bb8b758490287fd8be5cd Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Clarify the behavior of QDateTime around 24-hour transitionsEdward Welbourne2023-10-191-2/+90
| | | | | | | | | | | | | | | | | For those that simply repeat or skip a whole calendar day, life is fairly simple. However, Alaska's 24-hour transition at 15:30 LMT Sitka (incidentally combined with a change of calendar) is a bit trickier. Also fix a typo I noticed in passing. Write tests to determine what the actual behavior is and document enough to make the actual behavior seem unsurprising once encountered, without trying to go into all the excruciating details. Naturally, MS time-zone data lacks the data on the historic transitions involved in these tests, so MS (when not using ICU's time-zone data) is excluded. It seems Cupertino believes Alaska was always in the USA, too. Change-Id: Ia638c04d2ffc3a956a70a2a85badb7bbfdbb791c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QDateTime: disambiguate times in a zone transitionEdward Welbourne2023-10-192-42/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, requesting a time that got repeated - on the given date, due to a fall-back transition - would get one of the two repeats, giving the caller (no hint that there was a choice and) no way to select the other. Add a flags parameter that captures the available ways to resolve such ambiguity or select a suitable time near a gap. Add such a parameter to relevant QDateTime methods, including constructors, to enable callers to indicate their preference in the same way. This replaces DST-hint parameters in various internal functions, including QTimeZonePrivate's dataForLocalTime(). Adapted tst_QDateTime to test the new feature. Adapt to gap-times no longer being invalid (by default; or, when they are, no longer having a useful toMSecsSinceEpoch() value). Instead, they don't match what was asked for. Amend documentation to reflect that. Most of the code change for this is to QDTParser and QDTEdit. [ChangeLog][QtCore][QDateTime] Added a TransitionResolution parameter to various QDateTime methods to enable the caller to indicate, when the indicated datetime falls in a time-zone transition, which side of the transition to fall or whether to produce an invalid result. [ChangeLog][QtCore][Possibly Significant Behavior Change] When QDateTime is instantiated for a combination of date and time that was skipped, by local time or a time-zone, for example during a spring-forward DST transition, the result is no longer marked invalid. Whether the selected nearby date-time is before or after the skipped interval may have changed on some platforms; unless overridden by an explicit TransitionResolution, it is now a date-time as long after the previous day's noon as a naive reading of the requested date and time would expect. This was the prior behavior at least on Linux. Fixes: QTBUG-79923 Change-Id: I11d5339abef9e7125c4e0dc95a09a7cd4f169dab Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Sort out an anomaly in tst_QDateTime::springForward()Edward Welbourne2023-10-111-7/+2
| | | | | | | | | | | | | | | | | | | It noted that an unspecified function claimed the offset it was checking should be +1, while testing it against that or -1. The function turns out to be QDateTime::addDays(), whose doc did indeed, misleadingly, say that it lands after a gap it would have hit. It in fact overshoots the gap in the direction of its change. Amend its docs, likewise those of addMonths() and addYears(), to reflect the true behavior. Amend the test to look at the direction of the step its taking and anticipate that the adjustment will be in the same direction; then compare the actual adjustment to that. Change-Id: I9ab918fac0ab2195ef014983f37fccc435bf0498 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Let QDateTime::offsetFromUtc() work for invalid date-timesEdward Welbourne2023-10-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The implementation previously worked for non-short date-times, where the offset has been remembered since construction. This included the case of zoned times (and local times more than 2^55 msec away from the start of 1970) that hit a spring-forward's gap; but excluded local times that did the same (within 2^55 msec of the epoch). This precluded an offset check in a spring-forward test, now added. We can in fact determine the offset whenever we got a valid date and time (we do so in the course of initializing the object, and when asked for toMSecsSinceEpoch(), even when invalid), and we should not use the value of the recorded offset if we didn't get a valid date and time, so amend to always return 0 if we didn't get valid date and time and always report the correct offset otherwise. In the process, amend offsetFromUtc()'s computation to directly resolve the date-time, rather than doing so via toMSecsSinceEpoch(), which has to repeat decision-making offsetFromUtc() has already done by the time it calls it. Also amend toMSecsSinceEpoch() to return 0 if we didn't have a valid date and time to begin with, so it only attempts to produce a useful result in the case where construction attempted to resolve the date-time. Change-Id: I6574e362275ccc4fbd8de6f0fa875d2e50f3bffe Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Adjust msecs instead of offset for spring-forward resolution timesEdward Welbourne2023-10-111-9/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The resolution selects a point in time outside the gap, which will be represented by toMSecsSinceEpoch()'s return, despite the QDT object's isValid() returning false. Previously we retained the originally-calculated msecs, so as to keep date() and time() matching what was asked for. However, this required adjusting offset, which was not remembered for local times within 2^55 milliseconds of the start of 1970. This lead to an inconsistency between the offset from UTC reported for the resolution for a local time further from the epoch, or for a time-zone, and the actual offset from UTC at the time indicated by the return from toMSecsSinceEpoch(). Instead, retain the actually calculated offset (even if we aren't going to remember it) and adjust the msecs to the value that ensures toMSecsSinceEpoch() will get the selected resolution. This incidentally means that, when toMSecsSinceEpoch() has to re-resolve (for a local time within 2^55 msecs of the epoch), it avoids revisiting the complications of hitting the gap. In passing, change internal stateAtMillis() to take the QTimeZone it is passed by const reference, to save a copy (noticed during debug). Also tweak a comment in a test to be explicit about a default value. [ChangeLog][QtCore][Possibly Significant Behavior Change] When QDateTime is instantiated for a combination of date and time that was skipped, by local time or a time-zone, for example during a spring-forward DST transition, the invalid result's time() - and, in rare cases, date() - no longer match what was asked for. Instead, these values and offsetFromUtc() now match the point in time identified by toMSecsSinceEpoch(). Change-Id: Id61c4274b365750f56442a4a598be5c14cfca689 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Warn on failure to construct valid system time zone objectEdward Welbourne2023-09-152-2/+7
| | | | | | | | | | | | | | | | Also move some docs from asBackendZone() to systemTimeZone(), making clear that the system zone object is current at the time of creation and won't be updated if the system is reconfigured. Adapt some tests to fail and make clear that the system is misconfigured if no valid system zone is found. [ChangeLog][QtCore][QTimeZone] If systemTimeZone() is unable to identify a valid system time zone, it now produces a warning the first time it encounters the problem. Task-number: QTBUG-116017 Change-Id: Ia437d8a03ff3cbf2b2cd98e8a8c3aebe50c1ee32 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use the modern name for zone Asia/KolkattaEdward Welbourne2023-09-131-3/+6
| | | | | | | | | | The old name Asia/Calcutta is being phased out. We can't assign QTzTZP, so select between new name and old using a reference variable. In the process, fix a QCOMPARE() against bool to a QVERIFY(). Pick-to: 6.6 6.5 Change-Id: I7cd8a813f8a88c8ae4ba07213f04f4ad0860cec0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Update QTimeZone data to CLDR v43Edward Welbourne2023-08-071-3/+3
| | | | | | | | | | | Ran the script, no new IDs to add. Revised tests of Central Standard Time: America/Ojinaga has joined Matamoros for it, in Mexico. Pick-to: 6.6 6.5 Fixes: QTBUG-115732 Task-number: QTBUG-111550 Change-Id: I9b41d8c0156b9fbe3961dbe9a35d55493fc55501 Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
* QDTP: match local-time by preference to its zoneEdward Welbourne2023-07-212-2/+39
| | | | | | | | | | | | | | | | | | | | | | | | | When parsing a string whose time-zone part matches local time's name, use local time in preference to the QTimeZone with that name. The case is ambiguous, and the bug was already fixed (by something else) in dev, but this caused a failure in 6.2 through 6.5; and using local time is more natural to QDateTime in any case. The fix incidentally makes the the logic of the zone-resolution code more straightforward and a closer match to how findTimeZone() found the match. The issue was hidden from 6.6 by a change [*] to the handling of POSIX rules, that lead to plain abbreviations such as CEST and BST - for which the IANA DB has no entry - no longer being considered "valid" zones, despite being technically valid POSIX zone descriptors (effectively as aliases for UTC). [*] commit 41c561ddde6210651c60c0789d592f79d7b3e4d5 Pick-to: 6.6 6.5 6.2 Fixes: QTBUG-114575 Change-Id: I4369901afd26961d038e382f4c4a7beb83659ad7 Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Check validity of startOfDay() and endOfDay() match expectationEdward Welbourne2023-07-191-0/+6
| | | | | | | Task-number: QTBUG-68855 Change-Id: I7fd9dac7db0f29c21e2f6e7bf284d708620508cc Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Extend kludge-arounds in tst_QDate for AndroidEdward Welbourne2023-07-191-20/+32
| | | | | | | | | Amends commit eff0ffbd1bc32aff811bc85488ad962dfbbd7325 to handle problems with Android apparently not knowing about Kiritimati's whole-day transition. Change-Id: Ifadca32efd4436c75fd50c0467c742147ef181ed Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Correct name of Ukraine's zoneEdward Welbourne2023-07-101-3/+3
| | | | | | Pick-to: 6.6 6.5 Change-Id: I90066ad5ca4ee5f2483cb5eb3208fb9ba98c873d Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
* CMake: Make corelib tests standalone projectsAlexandru Croitor2023-07-056-0/+36
| | | | | | | | | | | | | | | | | | Add the boilerplate standalone test prelude to each test, so that they can be opened with an IDE without the qt-cmake-standalone-test script, but directly with qt-cmake or cmake. Boilerplate was added using the following scripts: https://git.qt.io/alcroito/cmake_refactor Manual adjustments were made where the code was inserted in the wrong location. Task-number: QTBUG-93020 Change-Id: I28b6d3815c5f43d2c33ea65764f6f3f8f129eaf3 Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add test-cases for QDate::{start,end}OfDay() at QDateTime's boundsEdward Welbourne2023-05-151-0/+11
| | | | | | Task-number: QTBUG-68855 Change-Id: Ic91cb5f9947ce5ee533fc77ae24a50376e139ab3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Sanitize the handling of limitations of the MS time-zone backendEdward Welbourne2023-05-151-25/+39
| | | | | | | | | | | | tst_QDate::startOfDay_endOfDay() and its _data() were in danger of growing a lot of ugly #if-ery to work round the known limitations of MS's time-zone API and the backend built on them. Replace the #if-ery with a flags enum indicating which parts we need to ignore on MS and limit the #if-ery to how those flags get exercised. Change-Id: I8657b4fba75f1aef1f3f9374e05f60354dc25e34 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Fix QTimeZone::offsetData() for the case without transitionsEdward Welbourne2023-05-111-8/+22
| | | | | | | | | | | | | | | | | | | | | | A zone without transitions, such as any UTC-based one, would previously return invalid data for the offset data at a given time. The method was documented to be "the equivalent of calling offsetFromUtc(), abbreviation(), etc" but these methods do return sensible data for a zone with no transitions. Furthermore, the backend data() method on which it depends is implemented by all backends, including the UTC one, with no transitions. Fix offsetData() to also return data when no transitions are available. Improve docs. Adapt the checkOffset() test to test offsetData() as well as the various functions to get parts of it. In the process, change that test to use a QTimeZone row instead of its name as a QByteArray, so that we can also have rows for lightweight time representations. Change-Id: I241ecf02a26a228cca972bca5e2db687fe41feb4 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* tst_QDateTime::springForward(): take account of differences among zonesEdward Welbourne2023-05-111-13/+42
| | | | | | | | | | | | | Some zones that fell into one or another of the supported groups had different start times or even dates for their transitions, causing the tests to fail in those zones. Adapt the test data to them. In the process, arrange for part of the test to report more: verifying a value is 1 or -1 sadly leaves no report of what it was when it wasn't. So use the scope-guard report pattern to do that on failure. Change-Id: I01cc4a90e3b45867ba0edb2d6c46397d465046ff Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Rework tst_QDate::startOfDay_endOfDay(), exploiting modern QTimeZoneEdward Welbourne2023-05-111-80/+70
| | | | | | | | | | | | | | | | | | | | | | | | QTimeZone is no longer dependent on feature timezone, only its backends are. We can also pass it as test data, rather than only its name. So replace the zoneName column with a plain zone column, make the UTC row for the epoch use QTimeZone::UTC instead of "UTC" and make only the remaining rows depend on the feature, and then only for their test using the backend zone. The test itself was doing some convoluted twists to check local time handled the relevant dates and times as expected. Where local time is the zone the test relates to, this can just as well be handled by adding a separate row for it - which we can even do without feature timezone. Otherwise, testing an expectation that local time *doesn't* have anything odd going on for the selected days was somewhat unreliable, as other zones that coincide with the tested zone for that particular date would fail. So just drop that unreliable side of the local-time testing. Change-Id: Id58b2d4cf7649567f1831154a605f31139e987d3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Correct startOfDay_endOfDay:BajaMexico test caseEdward Welbourne2023-05-111-4/+16
| | | | | | | | | | | | | This follows up on commit ca4aa065230d3524479f4a5cdbc077d11cc62e5d with a correction to the start of day, which should of course be 01:00, not invalid. Unsurprisingly, the MS backend doesn't know anything about that, so gets this wrong; kludge round it. In the process, adapt the kludge to the Sofia test-case to work the same way. Change-Id: If18e6d005783a0854c56092e695177898ec61712 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Add a distant-future local-time-type to tst_QDateTimeEdward Welbourne2023-05-041-4/+10
| | | | | | | | | | | | | | | It turns out glibc stops varying DST changes past where a 32-bit signed day-count from 1970 reaches (which, all things considered, can hardly be called a bug, for all that it's ...), at odds with QTZ's extrapolations from the current IANA DB rules. As the last date QDT can represent happens to be in the opposite side of everyone's DST from the one that leaves zones in, this lead to the 2038 local-time-type not reliably being useful for predicting the max-date behavior. So add a distant-future time-type that probes beyond glibc's cut-off, and have relevant tests check that instead of the 2038 one. Change-Id: If4e244d80fe2447da3bb9d5c406808c6c22c0a73 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* tst_QDateTime: rework initialization of local-time-typesEdward Welbourne2023-05-041-27/+29
| | | | | | | | | | | | | | There's no need to check the year or day-of-month (which involve calendrical calculations) when we can perfectly well just check the Julian Day number that's implied by the day-number parameters to setType(), which could just as well return the LocalTimeType to be assigned to the relevant parameter instead of doing the setting itself. With that rearrangement, making it into a private static method, the members it's used to initialize can then be const and initialized during construction. Change-Id: Ib7d295c3fbb9b90652952627456cdfb6176b8119 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Refactor QGregorianCalendar::julianFromParts to return std::optionalEdward Welbourne2023-05-041-13/+13
| | | | | | | | | It's a private static used to optimize internal use, so we can freely get rid of its out parameter this way. Change-Id: Id62612987f10ecbbd9702610fd172286adbfd442 Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Move some repeated constants from tests into tst_QDateEdward Welbourne2023-05-021-11/+2
| | | | | | | | Making them static constexpr class constants is tidier than duplicating them in diverse tests. Change-Id: I5a24c10d6db6f946581fa0523d28bdc80358e95e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* tst_QDateTime::springForward(): adapt tests for midnight transitionsEdward Welbourne2023-05-021-4/+4
| | | | | | | | | | | | | | | | | | The second pass through each test case, going via UTC, applied an adjustment to the time; however QTime wraps around modulo the day, so applying a negative adjustment to a time too near the start of the day could produce a time at the end of the day. I'm preparing to add some test-case variants for which the transition's UTC date differs from the date in the zone doing it, which trigger this. Combine the time with the date before applying the adjustment, so that the date gets decremented to match the time's wrap-around and conversion from UTC duly gets back to the correct place, not a day later. The new test cases (in an imminent commit) thus pass. Change-Id: I1bd5f191c7673a56ac3fbfc69eab0bc03c9e40b3 Reviewed-by: Mate Barany <mate.barany@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
* Fix problem with Australasian zones in fromSecsSinceEpoch() testEdward Welbourne2023-05-021-1/+16
| | | | | | | | | | | | | | | | | | | | | | It seems glibc's extrapolation of existing DST-rules cuts off at some point in the distant future, where the IANA DB gives no end-time for such rules, leading QTimeZone to keep applying them. This lead to tst_QDateTime::fromSecsSinceEpoch() not getting an invalid date in one of its bounds-probing tests, due to a within-bounds datetime getting glibc's offset and then the out-of-bounds one falling back to the IANA rule's offset that put it back within the bounds. This directly affected Australasian zones (which glibc locks into daylight-saving time in this distant future) which were fixed by using the IANA DB's offset; but the relevant date is in August so other zones, north of the equator, that glibc locks into standard time, then had the reverse problem, so we have to take the minimum of the two sources' offsets to get all zones on board. Change-Id: I0c94af2ba108dea31bee46aafa4a8cca8d373a5c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io> Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Correct Julian Day numbers in 1800Edward Welbourne2023-04-281-1/+1
| | | | | | | | | This follows up on commit b906796af62fb23e592625c7c86b31c98a08162b. Fix an off-by-one error - I was testing the last days of December 1799 and June 1800. Change-Id: I79ab622978d35f91e3e1b1b8d00d93b0d4b31c07 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Change QTimeZone's offset range into constants, not an enumEdward Welbourne2023-04-281-2/+2
| | | | | | | | | | | | | | Use static constexpr int values instead of abusing enum. [ChangeLog][QtCore][QTimeZone] The MinUtcOffsetSecs and MaxUtcOffsetSecs constants are now static constexpr members of QTimeZone, rather than members of an anonymous enum. Their values are now 16 hours either side of zero, to allow for some historical zones. Change-Id: I1c3a0f85a2b83b5010f021ca0f5ca5baefbf32e4 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io> Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* QDate: use more constexpr vars instead of plain numbersAhmad Samir2023-04-221-8/+10
| | | | | Change-Id: I95580c199f868d632324f7f1fcbd56fa4dc85958 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* tst_QDateTime: cope with MET masquerading as CETEdward Welbourne2023-04-201-4/+22
| | | | | | | | MET is an alias for CET, so the test's attempts to detect whether it's in CET can't distinguish them other than by checking the abbreviation. Change-Id: Ibb467d9bb2d983ca16302111b54f664a614057c2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Expand range of allowed UTC offsets to 16 hoursEdward Welbourne2023-04-201-4/+4
| | | | | | | | | It turns out that Alaska and The Philippines had historical offsets exceeding 15 hours, prior to day-transitions to bring their dates in sync with their respective sides of the international date line. Change-Id: I48fdf3aa6d8c0bacb368d08316733a10ee11a281 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix QDateTime tests in zones whose side of UTC variesEdward Welbourne2023-04-141-30/+32
| | | | | | | | | | | | | | The classification of local time as ahead of UTC, behind it or equal to it gets complicated by zones near the prime meridian - some of which have varied which side of it they nominally are - or the international date line, which a few zones have crossed. So, instead of having one classifying variable, split to having three, one for the distant past (when using local solar mean time), one for the epoch and one for the distant future. Change-Id: I7c0da376e1625372086dc51afa815756f0bde442 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Skip some tests that fail in the Indian/Cocos timezoneEdward Welbourne2023-04-141-17/+18
| | | | | | | | | | The zone had a transition at the start of 1900, so QDTP's default date ends up being 1900-01-01 at 00:02:20 instead of at 00:00:00; and any parsing of date-time strings that doesn't set the minutes and seconds consequently ends up "wrong" (about a field that wasn't specified). Change-Id: If4b9864616fa08bc023a6974dae255f96ca90f83 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* tst_QDateTimeParser::intermediateYear(): adapt for Indian/Cocos zoneEdward Welbourne2023-04-141-1/+3
| | | | | | | | | | | | The zone had a transition at the start of 1900, used as default date by the parser. This leads to the default minutes and seconds being 2 and 20, rather than 0. Since this test is parsing a date-only string, only check the date of the result, to avoid failing in Cocos. Pick-to: 6.5 Change-Id: Ifb307eadb747097988bcf0afc6f307835ff2c8ec Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-25 15:28:10 +0000