[Development] Status of QTimeZone

[John Layt]

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.