diff options
author | Edward Welbourne <edward.welbourne@qt.io> | 2022-08-31 15:43:48 +0200 |
---|---|---|
committer | Edward Welbourne <edward.welbourne@qt.io> | 2023-10-19 14:45:56 +0200 |
commit | a49ccc08c307b7c7e1acc34752b81dd38ea43bfa (patch) | |
tree | ba4194b766a80a9a687d13337158585e309753c6 /src/corelib/compat | |
parent | 38994ab9accc9aecf1139eb02f7e5fc75fccceec (diff) |
QDateTime: disambiguate times in a zone transition
Previously, requesting a time that got repeated - on the given date,
due to a fall-back transition - would get one of the two repeats,
giving the caller (no hint that there was a choice and) no way to
select the other. Add a flags parameter that captures the available
ways to resolve such ambiguity or select a suitable time near a gap.
Add such a parameter to relevant QDateTime methods, including
constructors, to enable callers to indicate their preference in the
same way. This replaces DST-hint parameters in various internal
functions, including QTimeZonePrivate's dataForLocalTime(). Adapted
tst_QDateTime to test the new feature.
Adapt to gap-times no longer being invalid (by default; or, when they
are, no longer having a useful toMSecsSinceEpoch() value). Instead,
they don't match what was asked for. Amend documentation to reflect
that. Most of the code change for this is to QDTParser and QDTEdit.
[ChangeLog][QtCore][QDateTime] Added a TransitionResolution parameter
to various QDateTime methods to enable the caller to indicate, when
the indicated datetime falls in a time-zone transition, which side of
the transition to fall or whether to produce an invalid result.
[ChangeLog][QtCore][Possibly Significant Behavior Change] When
QDateTime is instantiated for a combination of date and time that was
skipped, by local time or a time-zone, for example during a
spring-forward DST transition, the result is no longer marked invalid.
Whether the selected nearby date-time is before or after the skipped
interval may have changed on some platforms; unless overridden by an
explicit TransitionResolution, it is now a date-time as long after the
previous day's noon as a naive reading of the requested date and time
would expect. This was the prior behavior at least on Linux.
Fixes: QTBUG-79923
Change-Id: I11d5339abef9e7125c4e0dc95a09a7cd4f169dab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Diffstat (limited to 'src/corelib/compat')
-rw-r--r-- | src/corelib/compat/removed_api.cpp | 13 |
1 files changed, 13 insertions, 0 deletions
diff --git a/src/corelib/compat/removed_api.cpp b/src/corelib/compat/removed_api.cpp index 04af737add..bb3dca62a1 100644 --- a/src/corelib/compat/removed_api.cpp +++ b/src/corelib/compat/removed_api.cpp @@ -618,6 +618,19 @@ QStringView QXmlStreamAttributes::value(QLatin1StringView qualifiedName) const #if QT_CORE_REMOVED_SINCE(6, 7) +#include "qdatetime.h" + +QDateTime::QDateTime(QDate date, QTime time, const QTimeZone &timeZone) + : QDateTime(date, time, timeZone, TransitionResolution::LegacyBehavior) {} +QDateTime::QDateTime(QDate date, QTime time) + : QDateTime(date, time, TransitionResolution::LegacyBehavior) {} +void QDateTime::setDate(QDate date) { setDate(date, TransitionResolution::LegacyBehavior); } +void QDateTime::setTime(QTime time) { setTime(time, TransitionResolution::LegacyBehavior); } +void QDateTime::setTimeZone(const QTimeZone &toZone) +{ + setTimeZone(toZone, TransitionResolution::LegacyBehavior); +} + #if defined(Q_OS_ANDROID) #include "qjniobject.h" |