Bring out the asymmetry between date and time more clearly; when date
is valid, an invalid time is ignored in favor of QTime(0, 0). At the
same time, eliminate an un-needed variable from the code that
implements this special handling. (Left over from when the QTime was
passed by const ref, rather than by value.)
Change-Id: I81d8a9026cbb7887a8c638a2761b3db54c088af7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The QDateTimeData &d it's passed is a copy that's about to be
modified; before we do so, we haven't detached so its internals have a
ref-count of two, contradicting an assertion in the non-const
Data::operator->(); so just directly access d.d->m_timezone, since we
know that spec == TimeZone implies !isShort().
Added test that triggered the assertion and now doesn't.
Fixes: QTBUG-99668
Pick-to: 6.3 6.2 6.2.3 5.15
Change-Id: I07321ad91be5adce524be18e4ab82eee7110dc6a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
I was briefly confused about why an Etc/GMT+3 test was using GMT as
localtime. Fortunately I worked it out before mis-"correcting" it.
Change-Id: I7b0473c7d3974ef186e1170cf4999aca52aaaf45
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
On QNX, tst_QDateTime::fromStringStringFormat_localTimeZone_data()
failed to set up any rows for the data-driven tests to fetch, leading
to an assertion failure on trying to fetch a row.
Change-Id: I7c405b1142a8cb6d445b501ea44fe3d440570cf3
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
This was handled correctly when the backend supplies transitions
bracketing the time in question, but the fallback code tried to use
the DST offset at the time with larger offset from UTC; this did not
work when the gap was due to a change in standard time. Discovered by
ANS1 parsing of a date-time with two-digit year, for which the
date-time parser tried to use 1921-05-01T00:00 local time when filling
in the fields it had parsed; but, when run in Europe/Helsinki, there
is no such time due to the 20m 11s skipped when joining EET from the
prior local solar mean time.
Correct the calculation to use the actual change in offset from UTC,
as used in the (far better tested) between-transitions branch of the
code, rather than the DST offset after the transition.
Add a test-case based on the ASN.1 certificate date whose parsing
revealed the issue. Although it seems nothing in Coin can reproduce
the issue, the reporter has verified that the test does indeed fail on
the system where the bug was found and the fix does fix it.
Fixes: QTBUG-96861
Pick-to: 6.2
Change-Id: I12b02bad01daca2073d1a356452cd573684aa688
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This amends commit 68f19fb630 to only
consume one 't' from the format string, to match qlocale.cpp's
serialization of time-zone specifiers, which only consumes one, so
will repeat the time-zone specifier as many times as unquoted t
appears in the format. It's hard to imagine why anyone would want this
behavior, but it's what our serialization has always done and parsing
should match serialization.
Add test-cases for double time-zone specifier.
Delete a lie in the process.
Task-number: QTBUG-95966
Change-Id: I574896040a74085dee89a4fefd8384be44ad827b
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Various QDateTime tests relating to transitions
* used a nomenclature that made them confusing to thing about; and
* expected identically-initiallized variables to behave differently.
The latter, naturally, lead to "expected fail" tests.
Rewrote the tests to get the date-times they want to test at by means
that avoid the ambiguities inherent in QDateTime's lack of a way to
distinguish the two passes through the repeated hour in a fall-back
(QTBUG-79923) and added commented-out tests indicating what should be
true once that ambiguity is resolved. Verified the DST status is as
expected in the cases where that's the correct distinction between
date-times with the same date and time. Renamed various things to
(hopefully) make them more intelligible.
In the process, purged some leading 0s from numbers in code.
Fixes: QTBUG-68936
Change-Id: Id7a348995238b70dcb81a96edb8a3fa5315f86fa
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In my prior attempt to handle the last second of 1969, I forgot that
the QTime we're describing is a local time, so whether *it* thinks
we're at the last second of the day is beside the point. Fortunately,
preceding second should get -2 as return if mktime()'s initial -1
actually meant the last second of 1969, so we can test via that, after
a cheap pre-test to save doing this too often (albeit we only even
attempt the check if mktime() returned -1 in any case).
Restructured qt_mktime() in the process to deal with the error case's
early return promptly instead of doing it in an else clause. Also
repackage the calls to mktime to isolate various quirks and simplify
the logic in qt_mktime(). This also prepares for setting tm_isdst as a
hint when we know when we came from, in massageAdjustedDateTime().
Refined one test, added two more test cases. These didn't fail before
this fix, but a judiciously-placed qDebug() in testing revealed that
localMSecsToEpochMSecs() resorted to its fall-back handling - as if
the date-time were outside the time_t range - due to qt_mktime()
failing, for these test-cases (and several others). This fix evades
that fall-back behavior; a judiciously-placed qDebug() shows none of
our test-cases now fail callMkTime().
Change-Id: I11aa5015191dc4a565c28482307f7bc341c207e7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In setMSecsSinceEpoch(), the CET end-of-time is invalid anyway, so a
whole block (rather than just one sub-test of it) was irrelevant for
the max-qint64 test case (aside from verifying cet *is* invalid).
Split out to a separate test the part of a data-driven test that was
the same for all data rows. Reworked several ill-advised ways to use
QSKIP().
Change-Id: If757d3e722c81fc42a87256125ceef605b6bfb64
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When adding an offset from UTC, arithmetic may overflow. Likewise
when combining a date and time (that have been offset for UTC). Also
check the return from epochMSecsToLocalTime(), as it can fail; and pay
attention to the status stored by setDateTime(), to notice when it
hits an overflow. Fixed some tests that only passed because we
neglected these checks. Extended a test to check we detect overflow in
a couple of cases close to the extremes.
Change-Id: I127a670302f94a07bb9b087b1b9c608b7c08785c
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Øystein Heskestad <oystein.heskestad@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QDateTime has long followed a convention of ignoring what it knows
about time-zone transitions before the epoch. This produces unhelpful
artefacts (such as an ahistorical spring-forward skipping the first
hour of 1970 in Europe/London, which was in permanent DST at the time)
and complicates the code. It documented that DST transitions were
ignored, but in fact ignored all transitions prior to 1970 and simply
assumed that the current time-zone properties (half a century later)
applied to all times before 1970.
This appears to be based on the fact that the MS APIs using time_t all
limit their range to after 1970. Given that we have to resort to
"other means" to deal with times after the end of time_t, when it's
only 32-bit (and after year 3000, on MS systems), we have the means in
place to handle times outside the range supported by the system APIs,
so have no need to mimic this restriction. (Those means are not as
robust as we might want, but they are less bad than assuming that the
present zone properites were always in effect prior to 1970.) On
macOS, the time_t functions only reach back to the start of 1900; it
reaches to the end of its time_t range and Linux covers the whole
range. Given this variety, the range is now auto-detected the first
time it is needed (based on some quick and dirty heuristics).
Various CET-specific tests now need adjustments in tests of times
before the introduction of time-zones (when they are in fact on LMT,
not CET). The systemZone() test of QTimeZone can now restore its
pre-zone test cases. Various comments on tests needed updates.
[ChangeLog][QtCore][QDateTime] Available time-zone information is now
used to its full extent, where previously QDateTime used LocalTime's
current standard time for all dates before 1970. Where we have
time-zone information, it is considered reliable, so we use it. This
changes the "best efforts" used for times outside the range supported
by the system APIs, in most cases giving less misleading results.
Fixes: QTBUG-80421
Change-Id: I7b1df7622dd9be244b0238ed9c08845fb5b32215
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
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>
The prior tst_QDateTime::setMSecsSinceEpoch(-1) testcase was the last
millisecond of 1969; which (deep in the relevant function) actually
uses time_t 0 (with the -1 ms offset taken aside to be put back
later); so add the matching -1 second test. At the same time, add +1ms
and +1s checks for symmetry.
Change-Id: Ib487305f6ad81b55563ea59926cae13fb1fde592
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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
61b56a89a1, 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>
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>
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>
Instead of an XFAIL, actually test what we expect will happen for the
test, namely that the milliseconds will be lost. In the process,
verify that milliseconds since epoch also matches what was expected,
change an "expecting empty" condition to check for the "invalid"
test-case to which it's actually relevant and note that this test-case
shall need amended when we update our ISODate support to the 2019
update, which extends the year range.
Task-number: QTBUG-56552
Pick-to: 6.1 6.0 5.15
Change-Id: I680aa31ee0dcc8fadabb5d4cd6c083a8afd48573
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The test verified that a LocalTime's time since Epoch changes when the
system time-zone changes. This works when the QDateTime object is in
short form and recomputes its offset from UTC every time it is needed,
but fails with a pimpled QDateTime, as this caches its offset from UTC
when it is created, saving the recomputation which - in the far more
usual case where the system time-zone does not change in the lifetime
of a QDateTime object - would normally produce the same result.
Changed the test to use a newly-created QDateTime constructed with the
same parameters, which doesn't have the cached out-of-date knowledge
of its zone offset. Removed the XFAIL. Made the test data-driven and
added test-cases: one so close to the Epoch that it should be short
even on 32-bit systems, one so far that it's pimpled even on 64-bit
systems (used in reproducing the issue in order to debug it).
This then revealed that Android 5 doesn't seem to support the POSIX
zone IDs used by this test, so it now verifies that LocalTime has the
expected offset from UTC after zone changes, QSKIP()ping if not.
Documented that the behavior of LocalTime is undefined after a change
to the system time-zone. Cleaned up the existing doc of Qt::TimeSpec
in the process.
Fixes: QTBUG-89889
Pick-to: 6.1 6.0 5.15
Change-Id: I1058f47a1ff3ee1c326f3579ac80bd8bab242e28
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Amend ac970d48fd and use
QEXPECT_FAILURE for systemTimeZone test on 32bit systems.
Task-number: QTBUG-89889
Change-Id: I0eed35df871c69a20bcd7c544fc0e9a48dd8db7b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
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.
Pick-to: 6.0 5.15
Task-number: QTBUG-87435
Change-Id: I610e0a78e2aca51e12bfe003497434a998e93dc7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
systemTimeZoneChange() fails also on 32bit QEMU ARMv7.
Task-number: QTBUG-87663
Change-Id: I5c006a8637edff0a95b1f9b76d2c58006aeae6d6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
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>
Complete search and replace of QtTest and QtTest/QtTest with QTest, as
QtTest includes the whole module. Replace all such instances with
correct header includes. See Jira task for more discussion.
Fixes: QTBUG-88831
Change-Id: I981cfae18a1cabcabcabee376016b086d9d01f44
Pick-to: 6.0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
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
a04411119e .
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>
We want to re-enable Android tests in QTQAINFRA-3867. However,
many tests are failing already preventing that from happening.
QTBUG-87025 is currently keeping track (links) to all of those
failing tests.
The current proposal is to hide those failing tests, and enable
Android test running in COIN for other tests. After, that try
to fix them one by one, and at the same time we can make sure
no more failing tests go unnoticed.
Task-number: QTBUG-87025
Change-Id: Ic1fe9fdd167cbcfd99efce9a09c69c344a36bbe4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
RFC2822 requires times to be in the format 'HH:mm' or 'HH:mm:ss'.
We did not have unit tests to check that malformed RFC2822
dates are rejected. This patch adds such unit tests for
truncated hours/minutes/seconds.
Change-Id: Id5b9390112e633e617722439ad59439e6aeba841
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
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>
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>
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>
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>
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>
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>
The name toSecsSinceEpoch() gave no hint to the fact that the test
was, in fact, *also* testing round-tripping of the ISODateFormat.
Since there are other tests for string conversion, make this a simple
test of toSecsSinceEpoch().
It did the round-tripping via two methods with overly-terse names that
might just as well be local lambdas - now redundant, so removed.
Change-Id: I1e4fb1cc90224312c995596a8f3fe2bc5d9dfa15
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
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>
Add some unit tests using emojis as separator characters to check
utf handling.
Change-Id: I03c4bb5cd349e649c58e8a908c38a0185d80e722
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Modify special case locations to use the new API as well.
Clean up some stale .prev files that are not needed anymore.
Clean up some project files that are not used anymore.
Task-number: QTBUG-86815
Change-Id: I9947da921f98686023c6bb053dfcc101851276b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The test was previously using int; I shall be wanting to add tests
that exercise the bounds of qint64. Clean up the layout of the
test-row additions in the process of making a trivial change to them
all. Also const the QFETCH() types so we catch any use of non-const
methods on the values fetched.
Change-Id: I4b0187de71f5f14b39b4eabe8afd12a196f73d23
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The seconds and milliseconds default to 0; so omit them when they're
zero, unless there's nearby code that contrasts nicely with them.
Change-Id: Iea049015e976f5a5209fe87a2cbfdae9de49a559
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QTime() is invalid. Only the seconds and milliseconds are optional,
for valid times. Use startOfDay() for zoned times, QTime(0, 0) for
fixed-offset ones.
Change-Id: I3b65d5c3733ac83dc3a6c214859c3f56a480bb94
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Nothing used defDateTime(), nothing but it used defTime(). The only
other use of defDate() were from one test, which might as well make it
a local variable.
QDateTime's default is invalid, making invalidDateTime() redundant,
and the invalidDate() and invalidTime() it called had no other users.
Change-Id: I0e07ee58478bfe8ba680eafb52e2f73a962edd33
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Test data for QDateTime unit tests was constructed in system's local
time, which made unit test outcome dependent on the time zone of the
system running the tests.
This led to failing unit tests on systems with libc6 version
2.31 or newer. A QDateTime in a timezone, which has daylight saving
time, was created and then used in Hawaii's time zone,which has no
daylight saving time. Newer glibc checks this and returns errors.
This patch changes the behavior to create the test data in a
specified time zone setting.
Task-number: QTBUG-80441
Change-Id: I0330b647fa011be99141dde09001ff2d58bd3a5f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Instead of doing string formating first and then using QTest::newRow,
we can do both at the same time using QTest::addRow
Change-Id: Ia5c90eb705a806e37b96a1fa174a6557f91bee6d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
To not have to bother with encodings, a few QStrings are changed
to QByteArrays. This way, a few calls to QString::fromLatin1 and
to QString::toLocal8Bit can be removed
Change-Id: Ia0cf27fc2a86f9842ed0f3ebe47b050bb8a3f4e6
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>
QDateTime::toString uses the C locale since 5ba66c5622
So don't expect locale specific day- and month-names.
Task-number: QTBUG-80441
Change-Id: I08f53b6b33ed9e7eaaa58df4ca6a966c4ba9ef24
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
