147aa29162
QTimeZone("UTC") should be valid, as "UTC" appears in the list of availableTimeZoneIds(), and tst_QTimeZone::dataStreamTest() constructs timezones like this, which are considered valid. The internal representation of a QTimeZone("UTC") as created by QTimeZone::QTimeZone(const QByteArray &ianaId) is a QUtcTimeZonePrivate which isValid(), so the containing QTimeZone isValid() too. When QTimeZone is serialized into a QDataStream, it calls tz.d->serialize(ds) which is QUtcTimeZonePrivate::serialize. This writes QStringLiteral("OffsetFromUtc") followed by the IANA ID and the offset (etc.) to the datastream. When QTimeZone is deserialized it looks for this marker string, and if present, it passed all of the parameters to the QTimeZone constructor (not just the name). However, that constructor does not support standard IANA timezones (only custom ones), and when it detects that the supplied IANA ID is actually listed in availableTimeZoneIds(), it leaves the pointer to the QTimeZonePrivate uninitialized (NULL), which leaves the QTimeZone invalid (isValid() returns false). Thus, a valid timezone which was serialized and then deserialized has become invalid. This also affects serialization of QDateTimes with timezones. Fixed by calling the name-only constructor first, which works (only) for IANA standard timezones and leaves the QTimeZone invalid (isValid() returns false) otherwise. In which case, we can call the many-argument contructor to create a custom timezone with the same offset as the one which was originally serialized. [ChangeLog][QtCore][QTimeZone] Fixed sending IANA standard UTC-offset QTimeZones through QDataStream, which previously came out invalid after deserialization. Task-number: QTBUG-60595 Change-Id: Id9c47e8bda701faae4d800e012afb6db545b2fe9 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> |
||
---|---|---|
.. | ||
qtimezone.pro | ||
tst_qtimezone_darwin.mm | ||
tst_qtimezone.cpp |