summaryrefslogtreecommitdiffstats
path: root/src/corelib/time
Commit message (Collapse)AuthorAgeFilesLines
...
* QDateTime(Parser): code tidiesGiuseppe D'Angelo2021-05-252-22/+23
| | | | | | | | | | | | | Fixup a bunch of QFlags usage that ended up triggering implicit conversions. These conversions happen because QDateTime tries to save some space and shove a QFlags value in a bitfield, so there's no way around them; use explicit conversions instead. In other places: fix QFlags->bool conversions by using testAnyFlag. Change-Id: I50e8d92ed829b64ac46097c09e547e1c89cc2e35 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QDateTime: fix our oversight in Qt 6.0 not changing the ShortDataThiago Macieira2021-05-152-3/+11
| | | | | | | | For 32-bit systems. They're not important (to me), but might as well fix this oversight. Change-Id: I755911ae7d0341f49039fffd167b26617db93354 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QDateTime: code tidiesGiuseppe D'Angelo2021-05-131-3/+5
| | | | | | | | | | | | Move the ValidityMask / DaylightMask enumerators in the right enumeration. This allows to use them in a type-safe way through the StatusFlags flag type. Also, define the flag operators for StatusFlags. Change-Id: Icdba7c3f49f18ffb4aff9921d8012ddc3f7cbed7 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Use templated QJniObject::object() instead of static_castAssam Boudjelthia2021-05-061-9/+9
| | | | | | | Change-Id: I3bf366967d7995621aba1a7c1bec6732f3ef957d Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Ensure setDateTime clears status also when shortEdward Welbourne2021-05-041-1/+3
| | | | | | | | | | | Previously, if multiplication overflowed when trying to set the date and time of a formerly short-form QDateTime, its status didn't get set to reflect the failed validity check. Added a test that now correctly detects that it's produced an invalid date-time on overflow, where previously it produced a wrong valid date-time. Change-Id: Id46ca34d1e32e9b9b0630f3723cefd1c13b5761e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Revert early return from QTimeZone on invalid IDEdward Welbourne2021-04-291-3/+0
| | | | | | | | | | | | | | This reverts commit ec8808c3020abbc436f1a2d90fecf3245fd6417b but retains its test, as the problem it fixed is now solved by having the TZ backend validate the ID it's passed, so that it now only accepts valid POSIX zone-descriptions and valid IANA IDs. The former were being excluded by this check. Amended a POSIX test to fail with the check in place; it passes now. Change-Id: I0d5e8c6e0a315ac2509f3d23bebb52aede8f79d0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Robert Löhning <robert.loehning@qt.io>
* Handle invalid system zone case when falling back from time_t functionsEdward Welbourne2021-04-291-26/+30
| | | | | | | | | | | | | | Ammends commit 530e0bd469e6859269c2d1a792b8ce819fbff389, in which I added a QTimeZone-based fall-back for handling of conversions between local time and UTC when outside the range supported by time_t-based functions. That replaced prior kludges, when feature timezone is enabled; however, even with feature timezone, it's possible for the system zone to be invalid. So retain the old kludges also as fall-back for when the system zone is invalid, as well as when we have no timezones to fall back on. Change-Id: Ie2b8af7f1a87d7b0e39cc5ac0c04b04d574f84b5 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix mix-guided use of const reference variableEdward Welbourne2021-04-291-1/+1
| | | | | | | | It needs to be a mutable value variable to be std::move()d. Pick-to: 6.1 5.15 Change-Id: I9d78b2975f8964e7a7eb06771b0069d9b9e6661e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Check POSIX rules during QTzTimeZone creationEdward Welbourne2021-04-272-15/+65
| | | | | | | | | | | | | | | | | | | | | Previously, an apparent POSIX rule would be saved and any defects in it would only be discovered when trying to use it to generate transitions. Instead, check that it has the right form during the initial parsing of its data. In the process, since checking for DST in the process is trivial, implement a long-standing TODO to cache hasDaylightTime()'s answer. The array it scanned was in any case being scanned during construction, so detecting DST in init()'s scan is trivial; and its failure to check the POSIX rule mean it failed to notice when zones entirely specified by a POSIX rule have DST. Adapt a test using a POSIX-only rule to verify it does know the zone has DST; it did not, before this change. Change-Id: I690c013d3331600f7348dae61c35d41e5599da70 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix handling of a POSIX zone rule describing permanent DSTEdward Welbourne2021-04-271-17/+44
| | | | | | | | | | | | | | | | | | | | | | | | | The description necessarily has fake transitions at start and end of the year, potentially outside the year. These transitions should not be reported by QTzTimeZonePrivate as transitions, although its data() must find a "transition" whose data it can use (as in the permanent standard time case, which could potentially be represented the same way, although there's a saner way to do so, that the code already handles) to report the zone's properties. In the process, fix (and make more straightforward) the convoluted decision-making code that was deciding which transitions to include in the returned list. It was assuming invalidMSecs() would be set as the atMSecsSinceEpoch of a transition, although this is computed in a way that makes that value most unlikely, even when the result is invalid. It also rather confusingly mixed < 0 tests as tests for overflow with the one < 0 test that's about ignoring DST before 1970. Also added comments to clarify some of what's going on there. Expanded a recently-added test of a permanent DST zone to verify this now works correctly. Change-Id: Ia8d98f433fb1e479dba5479220a62196c30f0244 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Correct the parsing of POSIX rule day-of-year fieldsEdward Welbourne2021-04-271-8/+11
| | | | | | | | | | | | | | | | | There are two formats for such fields: one with a J prefix on a number in the range 1 to 365, the other with no prefix and a range from 0 to 365. The code mistakenly treated the latter as if its range were from 1 to 366. The J-form doesn't count Feb 29th, so March always starts on day 60; the code tried to take that into account, but adjusted in the wrong direction (and this mislead me, in a recent partial fix, into a fence-post error). Add a test-case based on the Africa/Casablanca POSIX rule seen on RHEL 8.2, which tripped over the off-by-one error without a J prefix. This incidentally also tests the J case. Change-Id: I692ca511e5c960f91a6c21073d3b2f037f5e445f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Update CLDR-derived data to newly-released v39Edward Welbourne2021-04-263-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 Pick-to: 6.1 6.0 5.15 Change-Id: I78ee161275b3c456c5800a7317a96947c932cf8e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Make zone-name part of date-time parsing a little fasterEdward Welbourne2021-04-231-2/+2
| | | | | | | | | | QDateTimeParser::findTimeZoneName()'s invalidZoneNameCharacter() check was using QLatin1String::contains(QChar), which converts the Latin-1 string to UTF-16 on each call, despite having pre-checked that the QChar is ASCII. So use memchr() instead. Change-Id: I011e2b4ba3be20711fc5005f62e4f9f6a392dd16 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QDateTime: Avoid compiler warning about issue impossible at runtimeRobert Löhning2021-04-211-1/+1
| | | | | Change-Id: I6e5f76582c4caff31c56bfb4badfcc318f299f51 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* In the POSIX zone parser, handle no-DST zones the same as name-onlyEdward Welbourne2021-04-201-3/+3
| | | | | | | | | | | | If parsing the standard time data brings us to the end of the zone info, there is no DST information to use later and it makes sense to record the zone as simply a fixed-offset zone. At the same time, handle the case of empty name in the standard time data; use the zone info as name rather than an empty string. Change-Id: I34d4ea25d93d821a937949730adee89d82105bc9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Correct the range of allowed hours for a POSIX rule's transitionEdward Welbourne2021-04-201-27/+14
| | | | | | | | | | | | | | | | | | | | A POSIX rule's transition time is allowed an hour in the range from -137 to 137; in particular, a negative hour is allowed, and used by some Greenland zones using Europe's time-of-transition which, as they are more than two hours west of Greenwich, happens before midnight. This means the time of transition can't be represented by a QTime(), so propagate the int that represents it to the code that consumes it; and treat parsing failure as an error rather than "correcting" it - if the transition time is given, it must be valid. Changed tst_QTimeZone::isTimeZoneIdAvailable()'s verification of validity to report the name of the zone it thought was invalid. (A later change, validating POSIX rules, caued this to fail for America/Nuuk without the present fix.) Change-Id: I5c9127ac34d878554dd0aca1c1c7338c7e0e1c28 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Make deserialization of QTimeZone less promiscuousEdward Welbourne2021-04-201-3/+6
| | | | | | | | | | | When asked to read an OffsetFromUtc record, it was trying the IANA ID it read in as a possible zone name. If the backend accepted the given ID as a zone name, however, the result might not be an offset-from-UTC zone. So extend the isValid() check it was doing on the result to at least check the zone has no DST and matches the record's offset. Change-Id: I46a95aeb2a4d66887fd56a58fa72fe5d3b568a00 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Return early from QTimeZone constructor if alleged IANA ID is invalidEdward Welbourne2021-04-201-0/+3
| | | | | | | | | | | | If the ID isn't even valid, don't waste cycles trying to make sense of it as identifying a time-zone. Add test of an invalid ID that provoked an integer overflow on trying to parse it as a POSIX zone specification. Fixes: QTBUG-92842 Change-Id: Ib80bbb88c11c0484ce0358acabbdc25c5bd8e0b3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix bug in QDateTimeParser::findTimeZoneName()'s length-limitingEdward Welbourne2021-04-201-1/+1
| | | | | | | | | | | The recent commit 0c9fc20e7ff7b4ff0f15e0b2c071ea834625dce9 missed the case of a slash after some invalid character. That could lead it to reinclude the invalid after previously working out it should ignore it. Change-Id: I3e29d2bf4d8df3878b581a969348ff5087b5d847 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Robert Löhning <robert.loehning@qt.io>
* Handle overflow in QTimeZonePrivate::dataForLocalTime() and its callerEdward Welbourne2021-04-202-19/+27
| | | | | | | | | If the final result is outside the representable range, we can only declare the given date-time invalid. Change-Id: Ibce09462048bf351199657a5da2c55bb3ce5b934 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Fix another compilation error in QDateTimeEirik Aavitsland2021-04-201-1/+3
| | | | | | | | | | Similar fix as 538e9fa5689a1afe0d821b84cdfeaa1656973083 : gcc 7.5, used e.g. on Jetson, is not able to resolve the add_overflow overload without help. Change-Id: I4d497480bb8dc82d7b1cbd13fda8e291935c8752 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Merge integration refs/builds/qtci/dev/1618564901Qt CI Bot2021-04-162-115/+162
|\
| * Use QTimeZone to determine offsets outside the system-function rangeEdward Welbourne2021-04-162-21/+61
| | | | | | | | | | | | | | | | | | | | | | | | Follow up on some comments saying "TODO Use QTimeZone when available" in converting times, outside the range supported by the system's time_t functions, between local or zone time and UTC. Since this required two formerly static functions in qdatetime.cpp to access QTimeZone's d-ptr, turn those into methods of QTZ's friend QDTPrivate. Change-Id: I27fe03d8eff9f4e98661263b1a1d4d830f4e7459 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
| * Extend time_t-based handling all the way to the end of time_tEdward Welbourne2021-04-161-100/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least some modern 64-bit systems have widened time_t to 64 bits fixing the "Unix time" problem. (This is even the default on MS-Win, although the system functions artificially limit the accepted range to 1970 through 3000.) Even the 32-bit range extends into January 2038 but the code was artificially cutting this off at the end of 2037. This is a preparation for using the same also all the way back to the start of time_t. In the process, simplify and tidy up the logic of the existing code, update the docs (this includes correcting some misinformation) and revise some tests. Fixes: QTBUG-73225 Change-Id: Ib8001b5a982386c747eda3dea2b5a26eedd499ad Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Catch invalid offset returns from QTimeZone backendsEdward Welbourne2021-04-162-10/+19
|/ | | | | | | | | | If the backends run into an error in computing the offset, they return INT_MIN; but they are valled via the front-end, which returns zero when the zone is invalid. So treat INT_MIN returns from the backend the same as the case of being invalid. Change-Id: Ic3c4dfe964dbfba4030c770213eca8a63e84736d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add the "Territory" enumerated type for QLocaleJiDe Zhang2021-04-1513-100/+116
| | | | | | | | | | | | | | | | | | | The use of "Country" is misleading as some entries in the enumeration are not countries (eg, HongKong), for all that most are. The Unicode Consortium's Common Locale Data Repository (CLDR, from which QLocale's data is taken) calls these territories, so introduce territory-based names and prepare to deprecate the country-based ones in due course. [ChangeLog][QtCore][QLocale] QLocale now has Territory as an alias for its Country enumeration, and associated territory-based names to match its country-named methods, to better match the usage in relevant standards. The country-based names shall in due course be deprecated in favor of the territory-based names. Fixes: QTBUG-91686 Change-Id: Ia1ae1ad7323867016186fb775c9600cd5113aa42 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* 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 Pick-to: 6.1 6.1.0 6.0 5.15 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>
* 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 Pick-to: 6.1 6.0 5.15 Change-Id: I83052b1b6888728c81135db22a9c6298ae439375 Reviewed-by: Robert Löhning <robert.loehning@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Merge integration refs/builds/qtci/dev/1616505582Qt CI Bot2021-03-231-1/+1
|\
| * Remove qualification for Julian calendarAlex Blasche2021-03-231-1/+1
| | | | | | | | | | | | | | | | | | The given qualification was wrong but also not needed in the first place, Fixes: QTBUG-92046 Pick-to: 6.1 5.15 Change-Id: Id28347fee2ef11ffcb0df8320b1025568b59de9c Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* | Restore support for reading /etc/timezone for system zone nameEdward Welbourne2021-03-231-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 Pick-to: 6.1 6.0 5.15 Change-Id: Ic270acb0d958e17dbc74a0ff93a5a1843c939678 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QTzTimeZonePrivate: provide correct data for before the first transitionEdward Welbourne2021-03-182-14/+24
| | | | | | | | | | | | | | | | We previously used the data for after the first transition; but the Olson database knows about local mean time for each zone, and it does get used by the system libraries, so systemZone will conflict with LocalTime once we use the time_t functions outside their 32-bit range (coming shortly). Record the pre-zone data during parsing and use it in the (fortunately only one) place that needs it. Discovered the issue in the course of debugging other issues while purging QDateTime of its wilful ignorance of pre-1970 DST. Change-Id: Icf957460fa3ccbaf5165e79f38ac68b450ecf98f Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Don't combine enum values from different enum typesVolker Hilsheimer2021-03-181-2/+2
| | | | | | | | | | | | Address static analyzer warning dceb66e05690ed1fb2f1455a9eb517f6. C++20 is deprecating arithmetic operations between unrelated enumeration types, and not all of the enums involved here are clearly bitmasks. Pick-to: 6.1 Change-Id: I61c9dcdc42ccd2b01a6208e067d216107672cc4d Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use QFile directly instead of via QTextStreamEdward Welbourne2021-03-161-13/+23
| | | | | | | | | | Follows up on a TODO comment that says QTextStream is less efficient. In any case, QFile has readLine() returning QByteArray, without conversion to QString, and the parsing is uncomplicated. Change-Id: I06e563df417692d3b6514a52a313a0ff55b0b52e Reviewed-by: Øystein Heskestad <oystein.heskestad@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix compilation error in QDateTimeAndrei Golubev2021-03-041-1/+3
| | | | | | | | | | | | | One of the changes done in 902505a0584959fed9d0784ab5308f9d70fe68a9 results in a compilation error: somehow an expression "int * enum value (with underlying type qint64)" has result type "long int" and thus the compiler cannot find matching add_overflow Return the qint64 cast back to overcome this Compiler: gcc 7.5.0-3ubuntu1~18.04 Change-Id: Iaca882762e812bef69ec325df5f59e02082a0130 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Simplify QDateTimeParser::fromString() to always record the date-timeEdward Welbourne2021-03-011-9/+3
| | | | | | | | | | | | | | Previously, *datetime was only written to if the parse was a success. When parsing a date-time that's invalid by virtue of falling in a spring-forward gap, the parser returns a date-time that is invalid but has a toMSecsSinceEpoch() suitable for use in creating a sensible interpretation of the parsed string (in offset by the width of the gap from the specified position in the gap). It is more useful to return this value than a default-created QDateTime. Change-Id: I89f39e729b1f9fede1532d8b82f6f676477ddadb Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Try again if mktime() fails when we thought we knew DST-nessEdward Welbourne2021-03-011-0/+6
| | | | | | | | | | | | | | | | | | When refreshing a QDateTime(,, Qt::LocalTime) we call mktime on data obtained from it, passing in the DST status (when known; this keeps two otherwise identical times in a fall-back distinct). One of the tests relies on changing zone under the feet of such a date-time, created in Hawaiian standard time; it serializes it, the reads it back in Western Australian Daylight-saving time and expects the results to be equal. However, the two differ in DST-ness, which leads to mktime() failing for the Hawaiian original, with unwelcome results. Notice this case, failure with DST-ness claimed known, and retry without the claim, so as to correct the DST-ness. Change-Id: Id0278df53130f76fc587769efe946ca9af1adc26 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QTimeZonePrivate::dataForLocalTime: avoid {ov,und}erflowEdward Welbourne2021-03-011-10/+21
| | | | | | | | | | | | | When computing a recent and imminent time, to bracket the time for which we want data, take care not to cycle round to the other end of the range of representable times. Rephrased comments on this function, in the process, to more accurately reflect what we're doing. Change-Id: Iacd36186abc6b19d0ca03981aec80b2c5af077b3 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Only store offsetFromUtc when sane (and assert sanity)Edward Welbourne2021-03-011-4/+8
| | | | | | | | | | | The addition of a sanity-assertion revealed that, for an invalid time-zone, refreshZonedDateTime() left epochMSecs unset but computed offsetFromUtc from it none the less. Leave it as zero in that case, or any other where the conversion to UTC didn't give valid date and time. Change-Id: I0ebd955798532e91e7e211bf065667e313ee5c2d Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Rework an assertion to eliminate a common sub-expression using a lambdaEdward Welbourne2021-03-011-8/+9
| | | | | | | | | | This take more lines but makes the condition clearer and the lines shorter, even after converting to use the names for constants in the condition. Change-Id: I9e5b7b79ff62095ed11b8723be238444fd32d9c1 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use qint64 as base-type for an enum mostly cast to that typeEdward Welbourne2021-03-011-45/+47
| | | | | | | | | | | | | Various constants used in qdatetime.cpp were cast to qint64() where used. There ware also some Q_INT64_C()s, two of which should have used members of this enum; the third suggested a new addition to the enum. Adding that and basing the enum on qint64 eliminates the need for casting, although one asprintf() does now require a cast back to int. There were also some redundant casts to qint64(), so I removed those. Change-Id: Ia51ad8020f037badb1506ca379da19098a8655f8 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix transitionEachZone() failures on AndroidEdward Welbourne2021-02-241-0/+5
| | | | | | | | | | | | | | | | | | | In QTimeZonePrivate::dataForLocalTime(), mistrust the Android backend's hasDaylightTime(), as it has a comment saying it only knows about future transitions, not past. This caller of it really needs to query "has ever had a transition", which this doesn't answer. Many zones that have no plans for future transitions have had transitions in the past; these were failing the transitionEachZone() test. In the process, refine the test itself, making sure we catch some quirk cases that shouldn't arise and making the debug message on failure more informative (while eliding the zone name, as this is part of the test name anyway, so added to the output by qDebug() itself). Fixes: QTBUG-69131 Change-Id: I88a0528182c247acb8b6327b40516178e455bcc0 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* 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. Pick-to: 6.1 6.0 5.15 Change-Id: I1802c49fa18818f4b4fe74f187da5f799df7d1de Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Provide calendar backends with a unique IDEdward Welbourne2021-02-1813-138/+292
| | | | | | | | | | | | | | | | | | | | Registration by ID allows for detection of duplicate instantiation of built-in back-ends, which can be detected and flagged by setting the ID to ~size_t(0) instead of the enum value for which it sought to be registered. A new method, calendarId(), is provided to access this; while the old calendarSystem() becomes non-virtual, as it can be inferred (when registration was successful) from the ID. Make registration by name or alias conditional on successful registration by ID. Previously, failed registration by name precluded registration by ID, which now becomes the authoritative registration. This incidentally makes it possible to add a QCalendar constructor taking the unique ID of a backend, for use in conjunction with custom calendar implementations. Change-Id: Ib22925a8ac3ef9439a09ec3855f6231cf9b91c21 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix a typo, simplify an increment, add an assertionEdward Welbourne2021-02-181-3/+5
| | | | | | | | | Trivial details picked up during the course of investigating a time-zone issue. Change-Id: I4d6e7ab1787a2500bd950e7f12ed8618a31f1f8e Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Drop some over-rides that duplicated the base-class's implementationEdward Welbourne2021-02-182-23/+2
| | | | | | | | | | | QAndroidTimeZonePrivate overrode the transition-related methods of its base, but there was no point in doing so, since our Android backend has no access to transition data, just the same as the base implementation. Change-Id: Ie4ff375381b463078b412f50e8ddc925ab1587a3 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Drop parsing of antique TextDate formatEdward Welbourne2021-02-151-27/+8
| | | | | | | | | | | | | | | | | | | | | | Apparently we used to have (back in 2007, only on Windows, incompatibly with what we were then using on Unix) a TextDate format (only for QDateTime, QDate used what it still uses) that put the day-of-month number, with a dot after it, before the month's short name. We have retained parsing of this format, on all platforms, ever since. It no longer matches the format we now use (since 5.2, in 2013, commit 61b56a89a1cf8a388ff925492700e5eef019c3aa, which harmonised the format with Unix and QDate); now seems like a good time to stop complicating our parser for its sake. [ChangeLog][QtCore][QDateTime] The parsing of Qt::TextDate in QDateTime::fromString() no longer supports the old TextDate format used (only) on Windows by Qt < 5.2 ("ddd d. MMM yyyy" with an "HH:mm:ss" time either appended or inserted before "yyyy"). Change-Id: I73a798ab78f187543e415119cc4a11f1cfd73820 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QDateTime::toString(): use UTC-offset as time-zone suffixEdward Welbourne2021-02-151-1/+2
| | | | | | | | | | | | | | | | | | | Since fromString() can't parse the (ambiguous at the best of times; also backend-dependent and thus potentially system-locale-dependent) abbreviations currently produced (since 5.9) and can parse UTC-based offsets, the OffsetName of the zone is a more robust format for the zone-suffix. This also makes it possible to consistently use the C locale, compatibly with everything else about post-6.0 date-time serialization. [ChangeLog][QtCore][QDateTime] When spec is Qt::TimeZone, the offset-suffix now used for the toString(Qt::TextDate) format is now a UTC-based offset string, compatible with the parsing (now) supported by fromString(). The zone-abbreviation suffix in use since 5.9 was not parseable. Change-Id: I4024ae87980c6d3590c68a67b8d1c8f433e36855 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Prepare TextDate to use UTC-offset rather than GMT-offset zone suffixesEdward Welbourne2021-02-151-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are GMT-offset zones whose convention for the sign of the offset is the reverse of what we are (still) using, which is the usual convention for UTC-offset zone: for example, the Olson Database's Etc/GMT+3 has offset -3 hours in the UTC-based system we use, so we give it suffix GMT-0300. The UTC-based suffix is also what we use as the abbreviation for OffsetFromUTC() in toString(). For now this only adds support for parsing a planned future form: the old form using GMT is retained, to give client code some chance to prepare for a backwards-compatible transition. Although the GMT prefix is matched case-insensitively, only match UTC if fully upper-case; there is no meaningful precedent for case-insensitive usage here. [ChangeLog][QtCore][QDateTime] The Qt::TextDate format now recognizes UTC-based offset suffixes in addition to suffixes based on the deprecated alias GMT. This prepares for toString() to use such UTC-based suffixes for time-zones (fromString() cannot parse the present abbreviation suffix). A future release of Qt shall use UTC-based suffixes in place of the present GMT-based suffixes (which conflict with GMT-based IANA zone names) for Qt::LocalTime and Qt::OffsetFromUTC time-specs. Client code is encouraged to use and recognize UTC-based zone suffixes in preparation for that transition, unless compatibility with versions before 6.2 is required. Change-Id: I5a42a488f1232a30f4b427b7954759283423b9b3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Update QDateTime::timeZoneAbbreviation docsEdward Welbourne2021-02-121-14/+14
| | | | | | | | | Include Qt::TimeZone as a possible spec, use a \list for the spec values. Incidentally use the public QTimeZone::abbreviation() instead of digging around in its privates to achieve the same effect. Change-Id: Ibabbeac9b085b4d09de46bda911356c20faadae8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-08 16:22:13 +0000