It needed re-implemented in terms of the new API (in case QTime(0, 0)
was skipped, on the date in question, by a spring-forwrd), which makes
it redundant (and supports choice of spec and zone or offset, which it
did not).
Change-Id: I1e3c3e794632c234f254be754ed6e4ebdaaaa6bc
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In Qt6 there is a behavior change with extra stuff after the seconds -
it's no longer allowed and will result in an invalid QDateTime.
This was introduced with bf65c27789 but
the autotests were not adjusted for it.
Change-Id: Iee6a9a7ac6cbb2754a68e082bb7074d17fac9d9c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
ISO date format doesn't allow spaces within a date, although 3339 does
allow a space to replace the T between date and time. Sixteen tests
added to check this all failed. So clean up the handling of spaces in
the parsing of ISO date-time strings.
[ChangeLog][QtCore][QDateTime] ISO 8601: parsing of dates now requires
a punctuator as separator (it previously allowed any non-digit;
officially only a dash should be allowed) and parsing of date-times no
longer tolerates spaces in the numeric fields: an internal space is
only allowed in an ISO 8601 date-time as replacement for the T between
date and time.
Change-Id: I24d110e71d416ecef74e196d5ee270b59d1bd813
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Cite RFC 3339 as basis for allowing a space in place of the T, too.
The RFC mentions that ISO 8601 accepts t and z for T and Z, so test
for them case-insensitively. Add a test for this.
Change-Id: Iba700c8d74d485df154d27300aab7b1958e1ccef
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If milliseconds were followed by a space, the space was included in
the count of "digits" read as the fractional part; since we read (up
to) four digits (so that we round correctly if extras are given), a
harmless apce could cause scaling down by too large a power of ten.
Since QString::toInt() ignores leading space, we were also allowing
interior space at the start of the milliseconds, which we should not,
so catch that at the same time. Added tests, including one for the
rounding that's the reason for reading the extra digit, when present.
Fixes: QTBUG-80445
Change-Id: I606b29a94818a101f45c8b59a0f5d1f78893d78f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QDateTime is a friend of QTimeZone, so can access its internals; but
it must check the zone is valid before doing so.
Expanded tst_QDateTime::invalid() and made it data-driven to catch the
failure cases.
Commented on a test-case that caught a mistake in my first attempt at
this, and on QDateTimeParser's surprising reliance on a quirk of
QDateTime::toMSecsSinceEpoch()'s behavior.
Fixes: QTBUG-80146
Change-Id: I24856e19ff9bf402152d17d71f83be84e366faad
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
The ones we reject used a zero offset while the one that does parse
(though it shouldn't - revised comment) has a one hour offset. Made
them all use that offset and added a partner test that has no invalid
characters, so ensure the success of the invalid character tests isn't
due to falsely rejecting the valid date/time text to which the invalid
characters are added.
Task-number: QTBUG-80038
Change-Id: I6e3dd79b981af6803e60877229c56599cfd719cb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The qdatetime implementation's rfcDateImpl() uses regexes which did
not match its comments; nor did either the regexes or the comments
match what was documented. A review of relevant RFCs suggests we
should revise this in future, probably at Qt 6.
The documentation also only addressed the formats recognized when
parsing a date-time, without indicating how they are serialised or how
dates and times are handled separately.
Added a note to the tests for the read-only formats, to remind the
reader that the RFCs merely recommend recognising these - be
permissive in what you expect and strict in what you deliver.
Change-Id: I0f0bec752e7a50bde98cceceb7e0d11be15c6a6f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A default-constructed QDateTime is invalid, but compared equal to a
valid one referencing the start of 1970. This lead to date properties
in QML being initialized invalid but not getting an onChange if the
first value they're set to is the start of 1970.
Fixing that then lead to some tests failing. Indeed, the original
equality check involved using toMSecsSinceEpoch(), whose value is
undefined unless the datetime is valid, without a prior check on its
validity: so ensure all uses of toMSecsSinceEpoch() are guarded with
isValid() checks.
Reworked tst_QDateTime::toSecsSinceEpoch() to use its bool column
(previously unused, after separating from toTime_t(), which uses this
column for "out of time_t's range") for validity of the datetime.
[ChangeLog][QtCore][QDateTime] Invalid datetimes are now treated as
equal and less than all valid ones. They could previously be found
equal to valid datetimes.
Fixes: QTBUG-79006
Change-Id: Ie72deb8af4350a5e808144d0f6e42dc8eb3ff5ef
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There is no year 0 in the proleptic Gregorian calendar, so QDate()
won't be happy if asked for a date in it. Tweak scanning of the data
we get from MS-Win so as to avoid a date calculation that could
otherwise happen in year 0 when constructing
QDateTime(QDate(1, 1, 1), QTime(0, 0, 0), QTimeZone("Australia/Sydney")).
Added a test for this case, which Oliver Wolff has kindly verified
does reproduce the assertion failure. However, Coin is unable to
reproduce, as all its MS builds are configured with -release, so
Q_ASSERT() does nothing. (The relevant code then skips over year 0,
albeit for the wrong reasons, and gets the right results, albeit
inefficiently, leaving no other symptom by which to detect the
problem.)
Fixes: QTBUG-78051
Change-Id: Ife8a7470e5bd450bc421e89b3f1e1211756fc889
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
These tests have not failed on the removed platforms for at least 60 days
Task-number: QTBUG-76608
Change-Id: If7a9f4db907124e3cd54e3f4b0ad3e20717d1912
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
- Replaced the usages of:
* QDateTime::toTime_t() -> QDateTime::toSecsSinceEpoch().
* QDateTime::fromTime_t() -> QDateTime::fromSecsSinceEpoch().
* QDate::shortDayName() -> QLocale::system().dayName().
* QTime by QElapsedTimer, where the deprecated methods of QTime
were used.
- Modified the tests for the deprecated methods to be enabled only
when the corresponding methods are enabled: when the deprecated
APIs are disabled, the tests will be also disabled, and the
compilation won't be broken.
Task-number: QTBUG-76491
Change-Id: I4d565db2329e580c567aae511696eb1efe120843
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
As planned when adding YearRange: now that it's merged up to dev, move
it to QDateTime, since we can add to the API at 5.14.0.
This follows up on commit 82ad4be4a2.
Change-Id: I81b6c2331121a71e2592514781c02c5756e70c52
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We'll be adding calendar code here as well, and tools/ was getting
rather crowded, so it looks like time to move out a reasonably
coherent sub-bundle of it all.
Change-Id: I7e8030f38c31aa307f519dd918a43fc44baa6aa1
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
