[Development] Status of QTimeZone
jlayt at kde.org
Mon Mar 25 22:43:41 CET 2013
I've just pushed another set of patches for the QTimeZone and QDateTime
changes. The current status is I think the code is now stable enough for a
final review and decision on whether to include in 5.1 or not.
The QDateTime changes for OffsetFromUTC and the formatter improvements can
certainly go in without QTimeZone as they address a number of open bugs and
clean up code.
I have added in a couple more reviews to change the QDataStream version number
(needed for QDateTime OffsetFromUTC), change the QDateTime debug stream
format, and add a new TimeSpec of ClockTime.
There are a few outstanding issues left:
1) QTimeZone needs a move constructor and operator, but my compiler errors on
my attempts apparently as it doesn't have the right level of C++11 support.
Is there an existing Qt class with it done the right way for lesser compilers
that I can copy?
2) There's a WIP proposal for adding a NoCountry value to QLocale::Country.
This is to help simplify the QTimeZone API where AnyCountry and NoCountry can
have different meanings, but it complicates QLocale as I note in the commit
3) I've separated adding QTimeZone support to QDateTime from adding support
for second occurrence as the second occurrence code is not ready and won't be
for a while due to problems with making it work with Qt::LocalTime. This
revolves around QDateTime's current behaviour with problems like the way it
doesn't handle the missing hour when clocks go forward, and mktime() behaving
differently on all 3 platforms. Until I have both TimeZone and LocalTime
working I can't add the new api required. I don't see this as a reason to
hold back QTimeZone as it is consistent with current behaviour.
4) The QDateTime QDataStream was changed in 5.0 to write all times as UTC, but
I think this is wrong. Qt::LocalTime is clearly documented as being the same
local time (i.e. ymd hms) regardless of the underlying system time or time
zone or any changes in the system zone. The consistent behaviour when
serialising would then be to save and restore as the local time and not its
UTC equivalent. For example if I serialise an alarm time of 7am local time, I
don't expect that to unserialise as 9am because I changed the system time
zone. If I want a time relative to UTC then I would use UTC, Offset or Time
5) tst_qdatetime on Windows with a European time zone throws up 8 failures for
me on a clean build without my changes. Does this happen for anyone else? Is
this test disabled in CI, because I don't see how anything could be passing
otherwise? I still need to investigate why, but the tests all fail with a
minimum qint64 msecs value.
6) Just a reminder that existing format/parse behaviour is maintained, i.e. we
will format the time zone but not parse it.
More information about the Development