Re: [Development] Status of QTimeZone
On 03/25/2013 10:43 PM, John Layt wrote: 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. Thiago, do you agree with John here? I think it makes sense, and the blame lies on me if so, but I did add you (John) as a reviewer: https://codereview.qt-project.org/#change,32966 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
I completely agree with that reasoning. Is it too late to restore the original behavior? I imagine the 5.0.x will be rather short lived with 5.1 coming out so soon so it seems like such a change wouldn't be all that terrible. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com On Apr 15, 2013, at 7:11 AM, Mitch Curtis mitch.cur...@digia.com wrote: On 03/25/2013 10:43 PM, John Layt wrote: 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. Thiago, do you agree with John here? I think it makes sense, and the blame lies on me if so, but I did add you (John) as a reviewer: https://codereview.qt-project.org/#change,32966 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
On segunda-feira, 15 de abril de 2013 13.11.25, Mitch Curtis wrote: On 03/25/2013 10:43 PM, John Layt wrote: 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. Thiago, do you agree with John here? Yes, I do. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
On 27 March 2013 20:11, John Layt jl...@kde.org wrote: On 26 March 2013 18:15, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 26 de março de 2013 14.07.56, Sergio Ahumada wrote: As far as I understand, the CI is all in Finland, so GMT +2. In other words, the tests are effectively disabled. Yeap, and on all platforms too. I assume changing the CI machines to CET is out of the question. I'd say to run the tests with TZ set to the right region, but on Windows that fails as while the C library respects the setting the Win32 api doesn't so it just breaks the tests in other interesting ways. So I guess we're left with modifying the tests to Finnish time, even though it just perpetuates the problem. All work up a patch once I've fixed the bug in Windows. John. FYi, the bug is in the tests, or more exactly Microsoft's poor handing of time zones. CET in the Olsen database doesn't apply Daylight Time before 1980, but Windows does. Up to now all the dates auto-tested before 1980 have purely by chance always fallen in Standard Time, but the new min test for qint64 in 5.0 falls into Daylight time thus exposing the difference. I'll amend the tests to expect Daylight time from Windows. John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
On 26 March 2013 18:15, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 26 de março de 2013 14.07.56, Sergio Ahumada wrote: As far as I understand, the CI is all in Finland, so GMT +2. In other words, the tests are effectively disabled. Yeap, and on all platforms too. I assume changing the CI machines to CET is out of the question. I'd say to run the tests with TZ set to the right region, but on Windows that fails as while the C library respects the setting the Win32 api doesn't so it just breaks the tests in other interesting ways. So I guess we're left with modifying the tests to Finnish time, even though it just perpetuates the problem. All work up a patch once I've fixed the bug in Windows. John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
Hi, 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? It fails for me, too; the tests are off by 1 hour, it seems. This is indeed a mystery. Is the CI in a European timezone? Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
On 03/26/2013 01:48 PM, Friedemann Kleint wrote: Hi, 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? It fails for me, too; the tests are off by 1 hour, it seems. This is indeed a mystery. Is the CI in a European timezone? the CI log shows: -- Testing tst_QDateTime Totals: 350 passed, 0 failed, 34 skipped -- for all the windows configurations (mingw47 and mscv2010 on Win7; msvc2012 on Win8). As far as I understand, the CI is all in Finland, so GMT +2. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
It fails for me, too; the tests are off by 1 hour, it seems. This is indeed a mystery. Is the CI in a European timezone? the CI log shows: -- Testing tst_QDateTime Totals: 350 passed, 0 failed, 34 skipped -- for all the windows configurations (mingw47 and mscv2010 on Win7; msvc2012 on Win8). As far as I understand, the CI is all in Finland, so GMT +2. This test contains a number of test cases that are only run if the local timezone is CET. They are silently skipped otherwise (test rows not added, rather than QSKIP) It certainly used to fail around the times of year that DST changes happen, when the CI was in Oslo. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
On terça-feira, 26 de março de 2013 14.07.56, Sergio Ahumada wrote: As far as I understand, the CI is all in Finland, so GMT +2. In other words, the tests are effectively disabled. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
