summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/time/qdatetime/tst_qdatetime.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix end-of-parse fixup of two-digit year in QDateTimeParserEdward Welbourne2024-04-191-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>
* Change license for tests filesLucie Gérard2024-02-041-1/+1
| | | | | | | | | | | | 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-191-12/+4
| | | | | | | | | | | | | | | | | | | | | 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-081-6/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Clean up QDate(Time)?::fromString() test-data tables, adding a columnEdward Welbourne2023-11-281-175/+167
| | | | | | | | | | | | | | | | | 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-211-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-131-10/+78
| | | | | | | | | | | | | | | | | | 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-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* 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-191-42/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* QDTP: match local-time by preference to its zoneEdward Welbourne2023-07-211-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* 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>
* 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>
* 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>
* 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>
* 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>
* Correct a test's precondition on the system zoneEdward Welbourne2023-04-141-3/+9
| | | | | | | | | | | | | America/Sao_Paulo was not alone in starting 2008-10-19 with a spring forward. Include the other affected zones in the check to tune the expected start-of-day time. See [0] for details. [0] https://github.com/eggert/tz/blob/main/southamerica Pick-to: 6.5 Change-Id: If251d8b715090319441790696983273637765d2e Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix where possible, else avoid, failures in western MexicoEdward Welbourne2023-04-141-18/+29
| | | | | | | | | | | Some QDateTime tests get tripped up by a transition at the epoch in Baja Mexico. For the operator_eq() and time-difference test, simply using startOfDay() instead of QTime(0, 0) - which was skipped - solves the problem. For addDays() and fromStringDateFormat(), skip the affected tests. Change-Id: I3620f0d1e4b05d9f799662eea96a40c8284de331 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* tst_QDateTime: Remove two duplicate test casesEdward Welbourne2023-04-141-5/+0
| | | | | | Pick-to: 6.5 6.2 Change-Id: I36541b5c6f7c35deee9678e2f736e1db9f36039f Reviewed-by: Jason McDonald <macadder1@gmail.com>
* tst_QDateTime constructor: adapt the year check to vary yearEdward Welbourne2023-04-141-9/+11
| | | | | | | | | | | | | | We check three sample dates, in different years, so don't compare their year() to 1970, but to their respective actual years. In the process, package the arrays iterated for these checks into a constexpr struct array and reverse them so that, instead of reverse-iterating and indexing, we can use a ranged-for loop. Change-Id: I214685346c637875a4ea31125c324851eb4308db Reviewed-by: Øystein Heskestad <oystein.heskestad@qt.io> Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io> Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* tst_QDateTime::addMSecs(): check for failure after calling helperEdward Welbourne2023-04-141-4/+9
| | | | | | | | | When the test failed, it did so in triplicate. Pick-to: 6.5 Change-Id: Ia871aed0a5960120a2659a6778c10dccd4b2953a Reviewed-by: Jason McDonald <macadder1@gmail.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Name a numeric_limits locally to save verbose repetitionEdward Welbourne2023-04-141-6/+7
| | | | | | Change-Id: I443eb1f5a38e79a28827ac3e664100e6a23a9ef2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mate Barany <mate.barany@qt.io>
* Corelib: s/Q_OS_MAC/Q_OS_DARWIN/wg except for doc and definitionEdward Welbourne2023-03-201-1/+1
| | | | | | | | | | I got tired of being told off by the inanity 'bot for faithfully reflecting existing #if-ery in new #if-ery. Retain only the documentation and definition of the deprecated define. Change-Id: I47f47b76bd239a360f27ae5afe593dfad8746538 Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Move qtLocalTime() to qtenvironmentvariables.cpp as qLocalTime()Edward Welbourne2023-02-031-1/+1
| | | | | | | | | | | | | | | The new name better matches the names of existing functions there. A comment on the old code noted that such a move should really be done, so as to correctly share the environment-mutex locking. In the process, move the (now three) time-related internal functions from qglobal_p.h to a new qtenvironmentvariables_p.h since that's the natural place for them given where they're defined (and the fact that they're for internal use only). Change-Id: Ib028baebaf31a806a2c0c97caaaba0a466c11cea Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Deprecate QDateTime methods using plain Qt::TimeSpecEdward Welbourne2022-12-101-0/+28
| | | | | | | | | | As foreshadowed when QDateTime adapted to route all QTimeSpec use through QTimeZone, this commit deprecates the old API in favor of the newly more capable QTimeZone-based API. Fixes: QTBUG-108199 Change-Id: I9a3f9f94d4a5d8cc229db72b3e4731a9e318a076 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Adapt corelib to use QTimeZone in place of Qt::TimeSpecEdward Welbourne2022-12-091-286/+301
| | | | | | | | | This saves (mostly in corelib/time/) some complications that used to arise from needing different code-paths for different time-specs. Task-number: QTBUG-108199 Change-Id: I5dbd09859fce7599f1ba761f8a0bfc4633d0bef9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Expand testing of QDateTime to exploit QTimeZone's handling of specsEdward Welbourne2022-12-091-20/+80
| | | | | | | | For now, just addDays() and the springForward() test, as proofs of concept for future work to be more systematic. Change-Id: Id2c4e9ad304d3aef6fdfb48ae6328df8c638c934 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Adapt QDateTime to route QTimeSpec uses via QTimeZoneEdward Welbourne2022-12-091-0/+53
| | | | | | | | | | | | | | | | | | | | | | Free most APIs using QTimeZone from feature timezone and route all APIs taking a naked QTimeSpec via these, in preparation for their eventual deprecation. Since qtimezone.h includes qdatetime.h (and MSVC blocks our ability to remove the need for that), qdatetime.h's declarations can't use a default value for QTimeZone parameters; so add overloads taking no zone (or spec) to handle that. [ChangeLog][QtCore][QDateTime] All QDateTime APIs involving a Qt::TimeSpec can now be routed via QTimeZone's lightweight time description support, saving the need to have different code paths for different time specs. In the process, QDateTime gains a timeRepresentation() method to return a QTimeZone reporting the (possibly lightweight) time description it uses. (The older timeZone() method always returns a non-lightweight QTimeZone, whose timeSpec() is Qt::TimeZone.) Task-number: QTBUG-108199 Change-Id: I23e43401eb2dbe9b7b534ca6401389920dd96b3c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* tst_QDateTime: explain one test-case more carefullyEdward Welbourne2022-12-071-2/+6
| | | | | | | | | | | | | | In the process, split some long lines. The test relies on omitting the hour (so as to get the default, 0) from both the format string and the string parsed, so as to test that the parser correctly handles the corner case where the zone skips the first hour of the day. This was not entirely obvious when reading the row data, so make it explicit in a comment. Change-Id: I919b292b78bd399a8749806a0e913d43f5b414e1 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mate Barany <mate.barany@qt.io>
* Add to test-cases for tst_QDateTime::fromStringStringFormat()Edward Welbourne2022-12-071-0/+6
| | | | | | | | Test a few more cases are correctly handled. Change-Id: I7f286ba93f59bf0168cac789cd30590f40e98cee Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* tst_QDateTime::operator_insert_extract() Correct handling of 4.0's specEdward Welbourne2022-12-071-2/+9
| | | | | | | | | The spec deseralized isn't a Qt::TimeSpec; handle it correctly instead of taking for granted that QDateTimePrivate::Spec's values happen to match. Change-Id: I67f3c960f3a3b90cdad3c1eca673f7ec8fd10b82 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* tst_QDateTime: check a few more detailsEdward Welbourne2022-12-071-1/+5
| | | | | | | | | | | | Mostly pedagogic checks in operator_insert_extract(), but also sanity-checking, to confirm spec conversions produce results equal to what each came from. In daylightTransitions(), verify the spring forward goes from standard time to daylight-saving time. Change-Id: Ieb9c603ee2eadecea055da4e8889528161f4d999 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* tst_QDateTime: Modernize some comparisonsEdward Welbourne2022-12-071-48/+52
| | | | | | | | | | | Use QCOMPARE(a, b) in place of QVERIFY(a == b), similar with QCOMPARE_LT() and QCOMPARE_LE(); and use a scope-guard to emit a message on failure instead of incurring the cost of building a string for the message, even when the passing test doesn't need it. Change-Id: I3884bc40e89a4b1ba881968b99faab27d4b1abc9 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Elide parameters passed as their defaultEdward Welbourne2022-12-071-106/+105
| | | | | | | | | | | Principally to get Qt::LocalTime mentions out of the way ahead of the QTimeZone work on Qt::TimeSpec, but also mop up trailing 0 parameters to QTime for seconds and milliseconds. Change-Id: I51041582faae100894a567c9e5ae96a60a3b2d8c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Mate Barany <mate.barany@qt.io>
* Prefer QDate::startOfDay() over QDT(date, QTime(0, 0), ...)Edward Welbourne2022-12-071-20/+20
| | | | | | | Change-Id: If02186791c2b8004b407b88393c132dc6d28a5ae Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Mate Barany <mate.barany@qt.io>
* tst_QDateTime::fromMSecsSinceEpoch(): remove a stray debug statementEdward Welbourne2022-12-071-2/+0
| | | | | | | | Left over from long ago, making confused use of Qt::hex. Change-Id: I7f411e4888ee1a637d2212fd6976dd003f8da9ce Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* tst_QDateTime: split some data table rows across lines more tidilyEdward Welbourne2022-12-071-29/+51
| | | | | | | | | Several were overlong (or soon to get so by being made longer); others were inconsistent with neighbors; one was inconsistent with itself. Change-Id: I272680499605a757e4827d27021bf234a91cf77a Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* tst_QDateTime: Inline some trivial delegations by _data() functionsEdward Welbourne2022-12-071-24/+4
| | | | | | Change-Id: Ib174a3ef1e4e913c6dc433b17854295cf529ad8f Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* tst_QDateTime::timeZone(): use QVERIFY() to test boolEdward Welbourne2022-12-071-8/+8
| | | | | | | Comparing to true and false doesn't enrich the output. Change-Id: Ie26a3f3d584f88310b8d4a31cad07be8dc8cb646 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* tst_QDateTime: eliminate some duplicate test-casesEdward Welbourne2022-10-171-9/+0
| | | | | Change-Id: I588494f2a79340599cafc48b3f4f4a79e6ca0a19 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Support serializing time-zone fields in date-times more flexiblyEdward Welbourne2022-09-291-2/+3
| | | | | | | | | | | | | [ChangeLog][QtCore][QDateTime] The 't' format character in a toString() template can now be repeated to get alternatives to the (unparseable) zone abbreviation. Thus 'tt' now gets the zone offset without colon, [+-]hhmm; 'ttt' gets the same with colon, [+-]hh:mm, and 'tttt' gets the zone name. Previously, each 't' was replaced by another copy of the abbreviation. Task-number: QTBUG-95966 Change-Id: Iccccd11f06fa732ed27c0e5d4e40a3d4b5f79f8d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Support parsing time-zone specifiers more selectivelyEdward Welbourne2022-09-291-4/+24
| | | | | | | | | | | | | | | | [ChangeLog][QtCore][QDateTime] The 't' format used in fromString() can now be repeated to restrict parsing to particular forms. Thus 'tt' now matches the [+-]hhmm offset format (no colon), 'ttt' the [+-]hh:mm offset format (with colon), and 'tttt' matches an actual zone name. When used singly, 't' still matches anything the parser knows how to interpret as a zone specifier. [ChangeLog][QtCore][QLocale] The 't' format in toDateTime() now has repeated forms, as for QDateTime::fromString(). Task-number: QTBUG-95966 Change-Id: I73753145cb66a56bc25a5c2dd5cb051ba982fa2c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Make time parsing accept zz as equivalent to zEdward Welbourne2022-09-131-3/+9
| | | | | | | | | | | | | | Expand a test to cover millsecond format variants more thoroughly, including a test for the new usage of zz. This applies to parsing the complement to commit 0a36a7c1db173089c25ea09029505a589a1c59e5's change to serialization. Fixed minor glitch in the serialization's doc, too. [ChangeLog][QtCore][QDateTime] When parsing a datetime, the 'zz' format specifier is now equivalent to 'z', as for serialization. Change-Id: I1c5700064738d9c92d5e8ce10bff8050131e190f Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-04 08:06:52 +0000