See attached test-case, after adding seconds to a valid KDateTime, the result is an invalid KDateTime, this is a regression from KDE4, and is causing a KCalCore test to fail Reproducible: Always
Created attachment 91344 [details] testcase output when running: Valid? true "1998-03-01T00:00:00-05:00" Last valid date "1998-03-29T00:40:00-05:00"
Any chance you'll look at this David ?
I'm sorry, but I don't expect to build a KDE 5 development system any time soon, so I'm not in a position to investigate it.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
This bug still occurs. I'll have another look at it.
The bug is actually in KTimeZone::toZoneTime(), but I haven't identified exactly where yet.
BUG DIAGNOSIS The date/time becomes invalid when in KTimeZone::toZoneTime(), the following line is executed (where 'dt' is a QDateTime instance): dt.setTimeSpec(Qt::LocalTime) Running the test with the system time zone set to Europe/London, 'dt' is set invalid when before the call 'dt' is 1998-03-29 01:00:00.000 UTC. This is when the Europe/London summer time change occurred, so that 1998-03-29 01:00:00.000 Europe/London is invalid. Rather than simply setting a flag to indicate that the local time zone should be used, QDateTime::setTimeSpec() evidently validates the resultant time against the current system time zone, even though the time is intended to be interpreted in a different time zone (America/New_York). REQUIRED FIX Fixing this bug would require significant changes to the KTimeZone and KDateTime classes. Given that, presumably, they will become obsolete in KDE 6, I don't think they are worth fixing. RECOMMENDED ALTERNATIVE TO KDateTime The class KADateTime in pim/kalarmcal is an updated version of KDateTime which uses Qt5 QDateTime time zone functionality instead of the much more limited Qt4 functionality used by KDateTime/KTimeZone. The issue does not exist in KADateTime, so KADateTime could be used as a substitute for KDateTime.