summaryrefslogtreecommitdiffstats
path: root/src/corelib/time
Commit message (Collapse)AuthorAgeFilesLines
* Update CLDR-derived data to newly-released v39Edward Welbourne2021-05-033-631/+632
| | | | | | | | | | | | | | Routine update with minor changes to locale data, no new languages, territories or scripts. Various Spanish locales change m_grouping_top from 1 to 2, reversing a change to a test of Costa Rica's currency formatting made in commit bb6a73260ec8272647265f42180963604ad0f755. Includes updates to time-zone IDs. Fixes: QTBUG-91478 Change-Id: I78ee161275b3c456c5800a7317a96947c932cf8e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 6235893d54b8fbf5c8bd54e33cd82b55042555f1) Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Make POSIX transition rule parser more robustEdward Welbourne2021-04-141-14/+29
| | | | | | | | | | | | | | | | | | | | | | | | | The POSIX rule parser used by QTzTimeZonePrivate recklessly assumed that, if splitting the rule on a dot produced more than one part, it necessarily produced at least three. That's true for well-formed POSIX rules, but we should catch the case of malformed rules. Likewise, when calculating the dates of transitions, splitting the date rule on dots might produce too few fragments; and the fragments might not parse as valid numbers, or might be out of range for their respective fields in a date. Check all these cases, too. Added a test that crashed previously. Changed QTimeZone::offsetFromUtc() so that its "return zero on invalid" applies also to the case where the backend returns invalid, in support of this. Fixes: QTBUG-92808 Change-Id: Ica383a7a987465483341bdef8dcfd42edb6b43d6 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Robert Löhning <robert.loehning@qt.io> (cherry picked from commit 964f91fd25a59654905c5a68d3cbccedab9ebb5a) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Restore support for reading /etc/timezone for system zone nameEdward Welbourne2021-04-121-7/+15
| | | | | | | | | | | | This restores one of the two mechanisms removed in commit b0383cbd388336f698ceeac11a4f50cdff931dd9, transformed to fit in with the new cached system-zone determination. Fixes: QTBUG-87326 Change-Id: Ic270acb0d958e17dbc74a0ff93a5a1843c939678 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 824d963700a91294ba4a543ebb486aedbd650284) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Avoid attempting to parse insanely long texts as zone namesEdward Welbourne2021-04-071-0/+18
| | | | | | | | | | | | | | | There are limits on zone name length and the trial-and-error approach we're more or less forced to take to parsing gets horribly expensive if applied to every prefix of a very long string. So apply a loosened version of the zone-name validity rule that limits the length of the fragments between slashes and limit the number of such fragments. Fixes: QTBUG-92275 Change-Id: I83052b1b6888728c81135db22a9c6298ae439375 Reviewed-by: Robert Löhning <robert.loehning@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 0c9fc20e7ff7b4ff0f15e0b2c071ea834625dce9) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Correct qt_mktime()'s check for last second in 1969Edward Welbourne2021-02-181-1/+1
| | | | | | | | | | | | It was comparing time->second() to MSECS_PER_DAY - 1, but time->second() is the second within its minute, so is at most 59. It should be comparing seconds into the day to SECS_PER_DAY - 1. Prompted by a PVS-studio article. Change-Id: I1802c49fa18818f4b4fe74f187da5f799df7d1de Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 94b9ee03b5646bf58c12337bbc44e38265ad15a2) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* QTzTimeZonePrivate::init(): fix handling of empty IDEdward Welbourne2021-02-021-7/+13
| | | | | | | | | | | | | | | | | We were using the first abbreviation in the list, where the current time's one is probably more apt. We look up displayName() using ICU, when in use, but that abbreviatio may be unknown to it. So ensure, when using abbreviation in place of empty id, that we get the system zone for ICU, for use if we're asked for the display name. This is a follow up to b12d6c6a8ab5f7b01bdd2cb862a66a409700faa1. Change-Id: I177db55de1ffbc763def8a0423642f2b3da74fa6 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 3c9013b76a6f4214f469613baf7ae5225b649660) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Update to CLDR v38.1, adding Yukon Standard TimeEdward Welbourne2021-02-021-221/+224
| | | | | | | | | | | | No change to QLocale's data, one addition to the Windows time-zone data. What was formerly "Us Mountain Standard time / Canada" is now Yukon Standard Time. Fixes: QTBUG-89784 Change-Id: I4c9a23620e74ea379be8a4c5ba0896d35fe9b594 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> (cherry picked from commit 05e67fbcab40ae702f58053d18cac567e805047a) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Correct string comparison in Android's IANA ID matching codeEdward Welbourne2021-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | It used QString.compare() and assumed it was returning a bool true on equality, when it actually returns an int that compares to 0 as the given strings compare. So it should use compare() == 0. This fixes several of QTimeZone's blacklisted tests on Android and a crasher, which we dodged with a QSKIP. Added an id-comparison to a test. Gave two local variables more informative names, made an early return into a QSKIP so it explains itself. Fixes: QTBUG-89905 Fixes: QTBUG-69122 Fixes: QTBUG-69132 Fixes: QTBUG-87435 Change-Id: Icf18ed5a810143d6e65d36e34a70e82faac10b8e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> (cherry picked from commit 6ee13db700eecd8dfed54a9ec2d1081b39511562) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix handling of Sunday in POSIX time-zone rulesEdward Welbourne2021-02-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | Dating from the origins of our support for the zoneinfo file format, the mapping of POSIX's day-numbering (0 = Sunday through 6 = Saturday, see [*]) to Qt's (1 = Monday through 7 = Sunday) was done by mapping 0 to 1, when it should have been 7. [*] http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html Corrected a QTimeZone test that trusted the results it got without checking which day of the week those were: they were all Mondays. Verified that the corrected dates are in fact Sundays. Checked the zone abbreviations, too. Fixes: QTBUG-90553 Change-Id: I84b4b14f9892ff687918cd3c42c7c9807e45313c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> (cherry picked from commit 38a72af4fd311219779f89b2b78cd56d879f61db) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Make QCalendar's backend registration reentrant-safeEdward Welbourne2021-01-261-32/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, different threads instantiating the same back-end could collide in the register, with various unwelcome results. Give Registry an atomic status flag to track whether it has been populated or is being destroyed; and protect it with a mutex to ensure distinct threads do not collide during registration or attempt to register while the registry is being destroyed. Document the correct way to instantiate custom backends, and that no code other than the QCalendar implementation should instantiate the built-in ones. Instantiators that follow these rules should be safe from failed registrations, provided they don't pick a name that conflicts with some other backend. They can also use the recent change to semantics of registerAlias() to verify that registration *has* succeeded. Done-with: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Task-number: QTBUG-88815 Task-number: QTBUG-85692 Fixes: QTBUG-84575 Change-Id: Ie78e700e71d610454152c05cafb38f6f713649ad Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 0180a1ab8229c6a15d19317bf7680663ac402910) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Hold references to zone IDs alive during useEdward Welbourne2021-01-211-2/+8
| | | | | | | | | | | | | Restore holding of a getID() call's return in a QJNIObjectPrivate eliminated in commit 78cde1bfd94521bbe4972f31a79c959d0990ea77; this keeps the Java internal object alive for its lifetime, where it might otherwise be garbage-collected before we're done with it. Fixes: QTBUG-88610 Change-Id: Id65b059012f7bd3377a6562c1b647feb75a13679 Reviewed-by: BogDan Vatra <bogdan@kdab.com> (cherry picked from commit d5eda37baaea20b2411b6ef1ca0d41a2a71a06a6) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix QTzTimeZonePrivate::displayName()'s fallbackEdward Welbourne2021-01-201-1/+2
| | | | | | | | | | It previously fell back on abbreviation, a very poor choice. The base class does better than that, so use its implementation instead. Change-Id: I47cbfce815cd8b2b533d9c6aeebcf398e5852d02 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit f9fff26b2db8152dcae26c92054f031bdebd7bc1) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix problems with offset-derived ids for QTimeZoneEdward Welbourne2021-01-192-15/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When creating a time-zone from a UTC+offset name that isn't known to the system, QTimeZone (since the fix to QTBUG-77738 in 5.15.0) falls back to constructing a suitable UTC-offset backend; however, the id of this is not guaranteed to match the id passed in to the constructor. In all other cases, the id of a QTimeZone does match the id passed to its constructor. Some utcOffsetId testcases had different id() than the id passed to the constructor, due to mismatches where a zone was constructed using the fall-back but the generated id included its minutes (as :00) or omitted its seconds. The omission of seconds is clearly a bug, but we also don't want to include :00 for seconds when it's not needed. So change QTimeZonePrivate::isoOffsetFormat() to accept a QTimeZone::NameType to configure how much we include in an id. Its callers other than the relevant constructor (from offset) still get minutes, even when :00, but will also get seconds added if that isn't zero; and the constructor from offset now gets the short form obtained by omitting all trailing zeros. Since all valid whole-hour offset names that do include :00 for the minutes field are in fact known standard offset names, the elision of minutes will only affect zones created by ID in the case of a whole-hour offset given without :00 minutes specifier, so these shall necessarily in fact get the ID passed to the constructor. Creating by UTC-offset with a name that specifies zero seconds will result in a QTimeZone instance whose id() differs from what was passed to its constructor (eliding the :00 seconds and potentially also minutes, if also zero) but this should be the only case where a QTimeZone's id doesn't match the one passed to the constructor, when constructed by id. Fixed inconsistency between the offset-constructor's declaration (taking offset as int) and definition (taking qint32) in the process. Added an id check to the utcOffsetId() testcase. Amended two tests of offset-derived time-zones' IDs, added comments to make clear how one of those differs from a matching standard name test and converted two uses of QCOMPARE(, true) to QVERIFY(). [ChangeLog][QtCore][QTimeZone] QTimeZone instances created by offset from UTC (in seconds) shall now only include minutes in their ID when the offset is not a whole number of hours. They shall also include the seconds in their ID when the offset is not a whole number of minutes. Task-number: QTBUG-87435 Change-Id: I610e0a78e2aca51e12bfe003497434a998e93dc7 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 50c63446f525a8625b6315597cb0897d89908d6b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Add test creating QDateTime in double-DST gap in 1947 GermanyAndreas Buhr2020-12-241-0/+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. Change-Id: Ib81a23914965f092c3e3195e4c7258e5a4e0b30e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 741862875c4bd72ba6d28cf53f6f88579602e4bf) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Restore previous QDateTime behavior in DST gapAndreas Buhr2020-12-171-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 Change-Id: Iecce5898bf9711a10e7dfc0a25e4bbeaed1c8ade Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 3d785249ba43cf4bd895ed679bac2791e0130dc5) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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. Change-Id: I44879bb441dbf51b96c8fd4d45e8f07423e63047 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit ac1008c16f58d95ae4ff0a7864e3bcb0783cc439) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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. Change-Id: I468ac364a68bf3574cd7f8b8b1e672d8fd969111 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 2b7c74d5ff7e835ffa76ed3c80b05cf73af40f4f) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Replace discouraged Q_MOVABLE_TYPE by Q_RELOCATABLE_TYPEAndreas Buhr2020-12-043-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. Change-Id: Ie653984363198c1aeb1f70f8e0fa189aae38eb5c Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> (cherry picked from commit 0440614af0bb08e373d8e3e40f90b6412c043d14) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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. Fixes: QTBUG-88656 Change-Id: If04cdbe65064108eaa87c42310527783ad21b4c0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 380d97e1bd15e753907c378a070bdf7f1c1cf06e) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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 Change-Id: If0b439038d5fe48eefb951c62f3aae2933bb5651 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 3a4115d1236bc78dda078657883283cc92df8e8a) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-05 09:58:41 +0000