summaryrefslogtreecommitdiffstats
path: root/src/corelib/time
Commit message (Collapse)AuthorAgeFilesLines
* Remove the qmake project filesJoerg Bornemann2021-01-071-71/+0
| | | | | | | | | | | | | | | | Remove the qmake project files for most of Qt. Leave the qmake project files for examples, because we still test those in the CI to ensure qmake does not regress. Also leave the qmake project files for utils and other minor parts that lack CMake project files. Task-number: QTBUG-88742 Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Add test creating QDateTime in double-DST gap in 1947 GermanyAndreas Buhr2020-12-241-0/+3
| | | | | | | | | | | In 1947, Germany had not only a summer time but also a "Hochsommerzeit", a high summer time. This patch adds a test creating a QDateTime in the time gap at the beginning of this Hochsommerzeit on May 11, 1947. Pick-to: 6.0 Change-Id: Ib81a23914965f092c3e3195e4c7258e5a4e0b30e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Restore previous QDateTime behavior in DST gapAndreas Buhr2020-12-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Historic QDateTime behavior when being asked to create a QDateTime in the DST gap was to interpret the given date as if it was in the time before that gap, mapping it to a point in time after the gap. This has changed with a04411119ead3d4473e4f0ac4bceedc585977b2f . Since then, the given date is interpreted as if it was in the time after the gap, thus being mapped to a point in time before the gap. This patch restores the historic behavior. This was not caught by Coin because machines ran in timezone "Atlantic/Reykjavik" which does not have DST since 1967. This patch changes tests to always run in "Europe/Oslo". Driveby: Test function "findSpring" did some operations in local time, even though being asked to work in a specific time zone. Fixed that. Fixes: QTBUG-86960 Fixes: QTBUG-89208 Pick-to: 6.0 5.15 Change-Id: Iecce5898bf9711a10e7dfc0a25e4bbeaed1c8ade Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Check date validity in calendar methods taking a QDateEdward Welbourne2020-12-101-2/+2
| | | | | | | | | Previously neglected, in dateFromParts() and dayOfWeek(), which only make sense for valid dates. Pick-to: 6.0 5.15 Change-Id: I44879bb441dbf51b96c8fd4d45e8f07423e63047 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Enable testing for whether a calendar registered its primary nameEdward Welbourne2020-12-042-25/+95
| | | | | | | | | | | | | | | | | In registerAlias(), return true if this instance is already registered with the given name. Previously there was no way for a QCalendarBackend to tell whether its primary name registration had succeeded, during instantiation (other than by devious hackery using a QCalendar instance with the name and some form of back-channel in the instance). Use this in backendFromEnum() to catch cases in which (e.g. due to a race condition) a new instance isn't the one that got registered. Pick-to: 6.0 5.15 Change-Id: I468ac364a68bf3574cd7f8b8b1e672d8fd969111 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Replace discouraged Q_MOVABLE_TYPE by Q_RELOCATABLE_TYPEAndreas Buhr2020-11-303-4/+4
| | | | | | | | | | | | | | Q_MOVABLE_TYPE was conceived before C++ had move semantics. Now, with move semantics, its name is misleading. Q_RELOCATABLE_TYPE was introduced as a synonym to Q_MOVABLE_TYPE. Usage of Q_MOVABLE_TYPE is discouraged now. This patch replaces all usages of Q_MOVABLE_TYPE by Q_RELOCATABLE_TYPE in QtBase. As the two are synonymous, this patch should have no impact on users. Pick-to: 6.0 Change-Id: Ie653984363198c1aeb1f70f8e0fa189aae38eb5c Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Return a more useful date-time on parser failure in spring-forward gapEdward Welbourne2020-11-271-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Up to 5.15.0, QDateTime::fromString(), when parsing a string that matched the format but represented a date-time in a spring-forward's gap, would return an invalid date-time object that represented a "best shot" date-time, correcting the error in the string as best it could. In 5.15, in order to handle time-spec information correctly, we adapted the date-time parser to have a fromString() variant that parsed a date-time as a whole, rather than as a date and a time; as a result, QDTP::fromString() now returns false and QDT::fromString() returned a default-constructed instance instead of the invalid date-time that QDTP had produced. Amend 76054516047d8efb8529443830bb4d9ddf01010f to restore the prior behavior of returning the invalid date-time object from QDTP instead of a default-constructed invalid date-time. Also document what this implies for the caller's ability to recover from the situation, if a best shot result is better than nothing. [ChangeLog][QtCore][QDateTime] Restored pre-5.15.0 behavior when parsing a date-time from a string (and document what it implies): if the string has the right form but represents a date-time that was skipped by a time-zone transition (e.g. a DST spring-forward), the invalid date-time object returned can, none the less, be used to recover a near-by date-time that may be more useful in some cases. From 5.15.0 to 5.15.2 and in 6.0.0, a default-constructed QDateTime was returned in place of this more informative invalid date-time. Task-number: QTBUG-88633 Pick-to: 6.0 5.15 Change-Id: If0b439038d5fe48eefb951c62f3aae2933bb5651 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QDateTimeParser: fix handling of AM/PM textsEdward Welbourne2020-11-271-8/+10
| | | | | | | | | | | | An AM/PM field is only fixed-width if the locale's AM and PM texts have the same length, which we shouldn't take for granted. (They're not in Albanian, Bosnian or Cherokee.) In sectionMaxSize(), count tells us the case, so we shouldn't be taking both case variants into account, only the one we need. Change-Id: I03b985cc5bf74c34742480558cef08af6343ed93 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Bounds-check time-zone offsets when parsingEdward Welbourne2020-11-272-12/+17
| | | | | | | | | | | | | | | Parsing of time-zone offsets should check the offset string conforms to the expected format and has valid values in its fields. The QDateTime parser, fromOffsetString(), neglected the bounds check on hours; the QTzTimeZonePrivate parser, parsePosixTime(), neglected all upper bounds checks, only checking against negative valus. Drive-by - refined phrasing of a comment. Pick-to: 6.0 5.15 Fixes: QTBUG-88656 Change-Id: If04cdbe65064108eaa87c42310527783ad21b4c0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QCalendar: increase coverage by testsEdward Welbourne2020-11-271-1/+2
| | | | | | | | | | | | Added tests for aliases and various calendar properties, ensured dateToJulianDay()'s invalid date branch is exercised. Corrected assertion when constructing from system and asserted calendarSystem() is as expected. Pick-to: 5.15 Task-number: QTBUG-88183 Change-Id: I510afcb5d9d115f68148d1f679f3224d712f92f4 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Prevent time zone lookup from using infinite amounts of memoryAndreas Buhr2020-11-191-6/+6
| | | | | | | | | | | | The QTzTimeZoneCache created one cache entry for every time zone which was looked up, even if the code was invalid. This uses some memory for each time zone code queried and thus allows DOS attacks if user supplied time zone codes are parsed. This patch changes the cache to use QCache instead of QHash and thus only store up to 100 zones in the cache. Change-Id: Ia87fe500b8b9cf23dced5448a33b047702515f19 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Update CLDR to v38Edward Welbourne2020-11-084-2957/+2977
| | | | | | | | | | | | | Fresh on the heels of our update to v37, they've released a new version. No new languages to complicate life, fortunately. Updated license (year range) and attribution. One test also needed an update: Catalan's long time format now parenthesizes the zone. Task-number: QTBUG-87925 Pick-to: 5.15 Change-Id: I54fb9b7f084b5cd019c983c1e3862dc03865a272 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Reorder locale enums alphabeticallyEdward Welbourne2020-11-084-4940/+4940
| | | | | | | | | | | | | Binary-incompatible change: change the numeric values of QLocale's Language, Script and Country enums, as encouraged by a comment in the generator script enumdata.py and clarify documentation around that. In the process (since I was changing almost every line anyway), convert the dictionary values from (mutable) lists of length two to tuples, since they are (and should be) immutable data. Change-Id: I26222bce45b9f5074b1d81ed70015a75ac34adcd Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Use newer names for various languages, territories and scriptsEdward Welbourne2020-11-083-90/+90
| | | | | | | | | | Our enumdata.py namings of countries had fallen somewhat out of sync with CLDR's names. In the process, support including hyphenation in the unsquashed name, along with spacing. Distinguish, in comments, between older renamings and those first seen in Qt6. Change-Id: I91ec444bf35222ab6a9332e389ace19cca0e4fdf Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Make QDateTime's operators hidden friendsEdward Welbourne2020-11-072-28/+57
| | | | | | | Update docs to match. Change-Id: I0ece9bcdba69c5dca48743894fe3347d9666f4e4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Make QTime's operators hidden friendsEdward Welbourne2020-11-072-19/+19
| | | | | | | Update docs to match. Change-Id: Ibcaeaea04fa552c392d49e711201719f99733742 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Make QDate's operators hidden friendsEdward Welbourne2020-11-072-21/+19
| | | | | | | | Adjust the documentation to match and add missing \c before false in two cases. Change-Id: Ic287c4de0b131c3500ee72bf1201900dc3788756 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Resolve corelib's remaining ### Qt 6 commentsEdward Welbourne2020-11-021-1/+0
| | | | | | | | | | | | | No action taken at Qt 6, suggesting it shall never happen. Four removed, one converted to Qt 7, others converted to unversioned TODOs. Filed Jira tasks, and referenced in comments, for those retained. There remain two "once bootstrap builds are obsolete" comments and one other on which pending action may yet happen. Fixes: QTBUG-85700 Change-Id: Ib140a6a21c63370e51e4734cc591f67573a29d9a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Adapt QDate::fromString() to accept negative year numbersAndreas Buhr2020-10-301-44/+80
| | | | | | | | | | | | | The documentation states that QDate::fromString() accepts negative year numbers, but it did not. This patch adds support for negative year numbers to QDate::fromString() and corresponding unit tests. Furthermore, tests are added for positive signs (+) in date strings. Fixes: QTBUG-84334 Task-number: QTBUG-84349 Change-Id: I575291e7b8317055d4bb530011d7b10c9cd37ae1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Add unit tests for QDateTimeParser internalsAndreas Buhr2020-10-301-0/+2
| | | | | | | | | | | | | | | | | | | | So far, the internals of QDateTimeParser and especially the handling of 'Intermediate' values were only tested implicitly by tst_qdatetimeedit. 'Intermediate' values are values which are not valid according to the specified format, but could become valid by adding more characters. This patch adds unit tests which tests parsing of these intermediate values directly. These tests will help implement handling of negative year numbers, where additional complications arise because of possible ambiguities between the minus sign '-' and the separator '-'. Task-number: QTBUG-84334 Change-Id: Ia6ba08df198288b8b11d3b2d2052c194f04fe8a1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Update CLDR to v37, adding Nigerian Pidgin as a new languageEdward Welbourne2020-10-263-2365/+2514
| | | | | | | | | | | | | | | | Routine update by running scripts, ignoring clang-format's extensive grumbles. Added notes to util/locale_database/'s README, on the need for that, and enumdata.py, on when to add entries. As usual, several new locales are also added, for existing languages, territories and scripts. [ChangeLog][QtCore][QLocale] Updated to new version of CLDR (the Unicode Consortium's Common Locale Data Repository) v37. Fixes: QTBUG-84669 Pick-to: 5.15 Change-Id: Ib76848bf4bd1219180faf46820077e8d8049a4e3 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Use unchecked substring methods in date-time codeEdward Welbourne2020-10-192-33/+31
| | | | | | | Change-Id: I38b9aaa0335c6168706c2508ed1117fd908e679c Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
* Check time-text is long enough while checking for its colonsEdward Welbourne2020-10-191-1/+3
| | | | | | | | | | Added some tests that trigger an assert without this check. (Drive-by: renamed one QTime test to match its QDate(Time)? counterparts.) Change-Id: I3d6767605fdcca13a9b4d43a32904f584eb57cf9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
* Fix some bad uses of QSharedPointerData::operator T*Allan Sandfeld Jensen2020-10-161-3/+3
| | | | | | | | Avoid detaching where possible Change-Id: I438d3e66689aeef05951af86a48af2a6910da7c2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* QTimeZone: drop an implicit conversion commentGiuseppe D'Angelo2020-10-161-1/+1
| | | | | | | | | The constructor isn't selected for conversions anyhow (it has more than one argument), and in Qt we don't mark such constructors as implicit (or explicit) anyways. Change-Id: I4203b946b9c6934aef9eead2db96154f9851ab9a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Check validity before adding to a QDateTimeEdward Welbourne2020-10-091-0/+9
| | | | | | | | | | | QDateTime's addDays(), addMonths() and addYears() neglected to check for validity before doing their job, with the result that they could produce "valid" (but wildly inappropriate) results if used on an invalid date-time. Added tests for this case (and the boundary). Change-Id: I7b0d638501cb5d875a678cde213547a83ed7529e Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Check against {und,ov}erflow in more QDateTime methodsEdward Welbourne2020-10-091-11/+39
| | | | | | | | | | QDateTime's range of possible values is wider than anyone generally needs, but let's not do confusing things when someone does overflow it. Change-Id: Ifbaf7a0f02cd3afe7d3d13c829bf0887eba29f7f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Check value is in range when setting a QDateTimeEdward Welbourne2020-10-091-5/+16
| | | | | | | | | | | | | | | | | | | Previously, a QDate representing more than about 0.3 gigayears before or after the epoch would overflow the millisecond count and produce a "valid" date-time that didn't represent the date and time passed to its constructor. Changed to detect such overflow and produce an invalid date-time instead, if it happens. Corrected some tests that wrongly expected to be able to represent extreme date-time values with every time-spec. The (milli)seconds since epoch are from UTC's epoch, so converting to another offset, zone or local time may give a value outside the actual range. Added some tests for the actual exact bounds. Task-number: QTBUG-68855 Change-Id: I866a4974aeb54bba92dbe7eab0a440baf02124f0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Allow millisecond-overflow when the result remains validEdward Welbourne2020-10-071-8/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even before adding support for fractional hours, a fraction of a minute might potentially have represented a whole number of seconds by a fractional part that, due to rounding, was less than the whole number of seconds by less than half a millisecond. Previously, the parsing would have clipped the fractional part at 999 milliseconds, in the preceding second, instead of correctly rounding it up to the whole second. For QTime::fromString(), which can't represent 24:00, and for TextDate, which doesn't allow 24:00 as a synomym for the next day's 0:0, applying such rounding to 23:59:59.999999 would produce an invalid result from a string that does represent a valid time, so use the nearest representable time, as previously. Added some tests and amended others. [ChangeLog][QtCore][QDateTime] QDateTime and QTime, in fromString() with format ISODate or TextDate, now allow a fractional part of the hour, minute or seconds to round up to the next second (hence potentially into the next minute, etc.) when this is the closest representable value to the exact fractional part given. When rounding up would turn a valid result into an invalid one, however, the old behavior of clipping to 999 milliseconds is retained. Change-Id: I8104848d246cdb4545a12819fb4b6755da2b1372 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
* Use fromIsoTimeString() in QDateTime::fromString() also for TextDateEdward Welbourne2020-10-071-37/+2
| | | | | | | | That way it'll be consistent with QTime()'s parsing of the time part. Change-Id: I3f66e5686ba6e2ea4bbc2d5a9a29a177de2d9e69 Reviewed-by: Andreas Buhr <andreas.buhr@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Use start of day when wrapping 24:00 to the next dayEdward Welbourne2020-10-071-2/+2
| | | | | | | | | | | | | | | Previously we used 0:0 on the next day, which might fall in a fall-back's gap. [ChangeLog][QtCore][QDateTime] When fromString() reads 24:00 in ISO format, it now uses the start of the next day, rather than 0:0 on the next day. This only makes a difference if the next day's first hour is skipped by a time-zone transition. Change-Id: Ib81feca5dc09fa735321b6ab76d5d118d6db6fd2 Reviewed-by: Andreas Buhr <andreas.buhr@qt.io> Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Break out calendar backend-from-enum as a static functionEdward Welbourne2020-10-061-27/+38
| | | | | | | | | | This lets the registry's populate() avoid recursing into constructors that are typically what (indirectly) called it. This, in turn, makes it possible to assert the constructor from enum gets what it expects. Pick-to: 5.15 Change-Id: I190f9dcfe405e3ee1c6a3f0926fa33cf9ddf64e0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QCalendar: fixup includesGiuseppe D'Angelo2020-10-061-1/+1
| | | | | | | | Remove an unused one, and add a used one. Pick-to: 5.15 Change-Id: Ic8b2fc7d0fa1e703b7cbbc622b98a626dd0f6ced Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Prefer QStringView's operator[] over its at()Edward Welbourne2020-10-061-7/+7
| | | | | | Change-Id: Ibe2c450aa69ac7ea6db1e6a2174e17f31b4be9a3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Implement date-time fromString(QStringView...) methodsEdward Welbourne2020-10-052-23/+98
| | | | | | | | | | | | | | | Inline the QString versions. One const QString & variant remains in each case: the date-time parser keeps a copy of the string it's been given, so the methods calling it have a hybrid method taking the string as the text to parse along with a view as the format. This avoids copying the string when the caller has an actual QString to pass in; the version with QStringView for both parameters has to toString() the text to be parsed, at some point on the way into the parser, but we can avoid that in the QString-accepting ones. Fixes: QTBUG-86172 Change-Id: I6a4390df90945af74a5eac2f0a752febd925ad62 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Centralize the implementation of move assignment operatorsGiuseppe D'Angelo2020-10-032-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment we have two main strategies for dealing with move assignment in Qt: 1) move-and-swap, used by "containers" (in the broad sense): containers, but also smart pointers and similar classes that can hold user-defined types; 2) pure swap, used by containers that hold only memory (e.g. QString, QByteArray, ...) as well as most implicitly shared datatypes. Given the fact that a move assignment operator's code is just boilerplate (whether it's move-and-swap or pure swap), provide two _strictly internal_ macros to help write them, and apply the macros across corelib and gui, porting away from the hand-rolled implementations. The rule of thumb when porting to the new macros is: * Try to stick to the existing code behavior, unless broken * if changing, then follow this checklist: * if the class does not have a move constructor => pure swap (but consider ADDING a move constructor, if possible!) * if the class does have a move constructor, try to follow the criteria above, namely: * if the class holds only memory, pure swap; * if the class may hold anything else but memory (file handles, etc.), then move and swap. Noteworthy details: * some operators planned to be removed in Qt 6 were not ported; * as drive-by, some move constructors were simplified to be using qExchange(); others were outright broken and got fixed; * some contained some more interesting code and were not touched. Change-Id: Idaab3489247dcbabb6df3fa1e5286b69e1d372e9 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Handle trailing cruft consistently in Qt::DateFormat parsingEdward Welbourne2020-10-031-71/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously the ISO time format would tolerate trailing cruft at the end in various cases even though there might be an offset specifier after the time, which should *not* be separated from it by anything (not even the spaces we originally planned to still tolerate). The RFC date format is forgiving about space, as is suitable for parsing of RFC-822 headers, but the other formats should match the handling in QDateTimeParser, which rejects any dangling cruft. At the same time, since this required a re-write of fromIsoTimeString() in any case, add support for the ISO format that gives the hour a fractional part and skips minutes and seconds. Previously we only had support for fractional minutes (with no seconds). The hour without even a fractional part is also valid. Reworked the documentation of Qt::DateFormat as it was wrong in places, inconsistent in its formatting and incomplete. Adjusted some tests to match the new behavior. A fraction separator with no following digits should have been recognized as an error previously and now is. [ChangeLog][QtCore][QDateTime] The ISODate and ISODateWithMs formats now reject trailing cruft (including spaces) at the end of a time string. They also gain support for parsing hour-only formats, including the hour-with-fractional-part format. Task-number: QTBUG-86133 Change-Id: I38ad1479ae033407f7df97ffbeb7c4bcd463d04a Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Modernize implementation in date-time and its parsingEdward Welbourne2020-10-023-54/+51
| | | | | | | | | | | | Convert several internal functions to use QStringView. Use QStringView's toInt(), now that it has one. Replace QLatinChar('*') with u'*' for each * found. Fix wrong-way-round separator bounds in one call to appendSeparator(). Change-Id: If5f11d9a82820133f390ae6270b16af72065cb54 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use QDateTimeParser::locale(), not the default QLocaleEdward Welbourne2020-09-301-2/+2
| | | | | | | | | | QDateTimeParser::parseSection() used the default locale instead of the one configured. Change-Id: Ie31aa87670cc5ceaf8d937a907807445f44bf7f9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andreas Buhr <andreas.buhr@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Eliminate QDateTimeParser's mutable parameters at lastEdward Welbourne2020-09-302-33/+30
| | | | | | | | | | | | | | | | I noticed that QDTP has a mutable member, text, which gets set at the end of each call to parse(); this makes all the in-out parameters redundant, since relevant methods can simply access - and modify - text, if it's set *at the start* of parse instaed. (There are no early returns to complicate matters.) This also makes StateNode::input redundant. At the same time, rename the mutable member, as several methods shadow it with parameter or local variable names; it is too generic. Change-Id: I2259cd87de5c84201b25c9633d11e59a4a4d57a1 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Standardize #include order and form in qdatetime.cppEdward Welbourne2020-09-301-20/+16
| | | | | | | | | There were duplicates; there was neither rhyme nor reason to the order. One was conditioned on a deprecated old define. Change-Id: Iba390f4a83758418379fb5fc522f08ada3e41d12 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Don't guess UTC when we can't find a system zone nameEdward Welbourne2020-09-283-16/+25
| | | | | | | | | | | | | | | | | | | | | | | | | If we're able to load a system zone without knowing its name, we shouldn't claim that its name is UTC. Instead, use the system zone information's name for the zone. Let the backend return an empty string if it can't determine the system zone ID, provided it has some way to get system zone info despite not knowing its name. This can happen on Windows if the system zone is one of Microsoft's idiosyncratic names that we don't recognize; or on Linux if /etc/timezone is a copy of a zoneinfo file, instead of a symlink. In support of that, handle empty ID as a request for system zone info, so that the backend constructors taking an IANA ID never get passed an empty ID; that gets routed to the default constructor instead. This incidentally restores QTzTimeZonePrivate's behavior, for empty ID, of reading the content of /etc/timezone if we are unable to determine the name of its zone any other way. Fixes: QTBUG-86306 Pick-to: 5.15 5.15.1 Change-Id: Iad57c18199124f651ebc3d32c3deffca6eaab512 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QCalendar: use LGPL like everything else, not GPLEdward Welbourne2020-09-271-5/+15
| | | | | | | | Pointed out by Lars. Change-Id: Idb8427d77b35c84eb3037703957cf7f93ea5f387 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Replace Q_REQUIRED_RESULT with [[nodiscard]]Allan Sandfeld Jensen2020-09-252-14/+14
| | | | | | | It was already used many places directly making the code inconsistent. Change-Id: I3b14bc6c333640fb3ba33c71eba97e78c973e44b Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QDateTime change documentation to reflect usage of C localeAndreas Buhr2020-09-231-48/+28
| | | | | | | | | | In the past, string formatting and parsing was done in the users locale. Now, the C locale is consistently used in QDate(Time) and localized functions are offered in QLocale. This patch reflects this change in the documentation. Change-Id: I81afda9063fa232d06841d63f69e19b49f8083f3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add a ValidWhenMask to QDateTimePrivate::StatusFlagEdward Welbourne2020-09-232-14/+6
| | | | | | | | | This saves some repetition of verbose status-setting code. At the same time, save the function that uses it a repeated getStatus() call hidden inside its getSpec() by inlining getSpec(). Change-Id: I32aee521c1885408f822ecb47ab1ed76f92852a1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Make QDateTime() unconditionally noexceptEdward Welbourne2020-09-232-6/+7
| | | | | | | | | As proposed by Lars in code-review; its Data::Data() is in fact noexcept even when CanBeSmall is false. Task-number: QTBUG-86400 Change-Id: I351e4332660f5895fff34b950227cbb811fd9f81 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Assert some conditions instead of testing for themEdward Welbourne2020-09-231-14/+7
| | | | | | | In one case, handle an error by an early return so that we can do so. Change-Id: If98eaaf2dfd47c1df1d09497fcc3e9ab784dc6df Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Make more consistent use of m_offsetFromUtc()Edward Welbourne2020-09-232-19/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | In QDateTime::toMSecsSinceEpoch(), all non-short date-times know their offsets from UTC, so can use that, saving the TimeZone ones the need to call (costly) zoneMSecsToEpochMSecs() and, when not short, the LocalTime ones the need to call localMSecsToEpochMSecs(). Moved the setting of offset clear of refreshZonedDateTime()'s check that the date and time match the milliseconds being handled, so that a sensible offset value is set even when the date-time comes back invalid due to being in a spring forward. As refreshZonedDateTime() now sets d's m_offsetFromUtc for both specs, it no longer needs QDateTimePrivate::setUtcOffsetByTZ(). In any case, the private time-zone access that provided is equivalent to the difference we already have between msecs and epochMSecs, except in a zone-gap. Add assertions to confirm this in zoneMSecsToEpochMSecs(). This brought to light a problem with whole-day transitions, where QDate::startOfDay() assumed the gap it was hitting would end by end of day. Search backwards from noon tomorrow, instead; likewise, for endOfDay(), search forward from yesterday. Task-number: QTBUG-75585 Change-Id: I6151d1dfccab321605753c98e01152281461bfe2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use same-msecs optimization more in QDateTime comparisonEdward Welbourne2020-09-231-2/+33
| | | | | | | | | | | | QDateTime's comparisons just compare milliseconds when both values are local times and their statuses (hence DST-ness) match. It can do the same for time-zones. While doing the same for UTC and fixed offsets wins nothing, it also costs nothing, given that we're already checking the spec. Task-number: QTBUG-75585 Change-Id: Ib6d824569aba8def2f1319ef3a11cca6869a5b5e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-27 04:17:33 +0000