Hi, 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 message. 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 Zone. 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. Cheers! John. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
