my own kdatetime patches: toString with InvalidOffset; operator==

[David Faure]

diff --git a/kdecore/date/kdatetime.cpp b/kdecore/date/kdatetime.cpp
index 910e1cf..74e82ca 100644
--- a/kdecore/date/kdatetime.cpp
+++ b/kdecore/date/kdatetime.cpp
@@ -1773,6 +1773,8 @@ QString KDateTime::toString(TimeFormat format) const
             offset = d->timeZoneOffset();   // calculate offset and cache UTC value
         else
             offset = tz.isValid() ? tz.offsetAtZoneTime(d->dt()) : d->specUtcOffset;
+        if (offset == KTimeZone::InvalidOffset)
+            return result + QLatin1Char(tzsign) + QLatin1String("invalidtz");
         if (offset < 0)
         {
             offset = -offset;

Without this fix, an invalid timezone led to a string representation like this:
  KDateTime(2012-10-19T00:00:00--596523:-14)
Nasty overflow in there, leading to '-' as a char followed by a negative number ;)
(This is due to InvalidOffset being equal to 0x80000000)
Now it prints:
  KDateTime(2012-10-19T00:00:00+invalidtz)
which is at least readable. It's invalid, of course, but it's readable :)
Should it say something else?


For the curious: this is how I triggered this issue:
running kdatetimeedittest in an isolated kdelibs-frameworks-with-qt4 environment.

QSYSTEM: KDateTimeEditTest::testDefaults() 20:12:01 KSystemTimeZones: ktimezoned initialize() D-Bus call failed:  "No such object path '/modules/ktimezoned'" 
QDEBUG : KDateTimeEditTest::testDefaults() 20:12:01 instance(): ... initialised
QDEBUG : KDateTimeEditTest::testDefaults() 20:12:01 readConfig(): local zone= "America/Los_Angeles"
QDEBUG : KDateTimeEditTest::testDefaults() 20:12:01 readZoneTab( "/home/dfaure/.kde-unit-test/kdatetimetest/zone.tab" )
PASS   : KDateTimeEditTest::testDefaults()
QSYSTEM: KDateTimeEditTest::testValidNull() 20:12:01 Cannot open  "/home/dfaure/.kde-unit-test/kdatetimetest/America/Los_Angeles" 
QDEBUG : KDateTimeEditTest::testValidNull() 20:12:01 KDateTime(2012-10-19T00:00:00--596523:-14)

The last line is from this patch:

--- a/kdeui/tests/kdatetimeedittest.cpp                                                                                                                                                   
+++ b/kdeui/tests/kdatetimeedittest.cpp                                                                                                                                                   
@@ -52,6 +52,7 @@ void KDateTimeEditTest::testValidNull()
     m_edit = new KDateTimeEdit(0);
     QCOMPARE(m_edit->isValid(), true);
     QCOMPARE(m_edit->isNull(), false);
+    kDebug() << m_edit->dateTime();
     m_edit->setDateTime(KDateTime());
     QCOMPARE(m_edit->isValid(), false);
     QCOMPARE(m_edit->isNull(), true);

Still not sure why I can't reproduce this in kdatetimetest.cpp though. Probably because it plays with tzset and stuff.

Sounds like this toString() fix should even go into 4.9?

The other issue (the one that made me debug all this) is that
bool KDateTime::operator==(const KDateTime &other)
doesn't handle the case where one is invalid and other is valid.
It ends up calling toUtc() on both, and that can be equal (to 0).

How about this fix?

--- a/kdecore/date/kdatetime.cpp
+++ b/kdecore/date/kdatetime.cpp
@@ -1357,6 +1357,8 @@ bool KDateTime::operator==(const KDateTime &other) const
             return d->secondOccurrence() == other.d->secondOccurrence()
                &&  d->dt() == other.d->dt();
     }
+    if (d->specType == Invalid || other.d->specType == Invalid)
+        return false;
     // Don't waste time converting to UTC if the dates aren't close enough.
     if (qAbs(d->date().daysTo(other.d->date())) > 2)
         return false;

[at this point we know already they are not equal]

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5