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

[David Faure]

On Thursday 25 October 2012 16:30:20 Jon Severinsson wrote:
> I triggered this in Qt5 too, and I figured out the underlying reason for it
> to  happen. If, when KSystemTimeZonesPrivate::setLocalZone() tries to
> figure out what time zone to use for KSystemTimeZones::local(), the kconfig
> "ktimezonedrc"/ "TimeZones"/"LocalZone" time zone does not exist in the
> kconfig  "ktimezonedrc"/"TimeZones"/"ZoneinfoDir" directory, it will create
> a "valid" KTzTimeZone with garbage data.
> 
> This happens because KDateTimeTest::cleanupTestCase() successfully removes
> the  temporary zoneinfo dir it creates, but used the wrong path when trying
> to remove the ktimezonedrc kconfig file.
> 
> Patches for both KDateTimeTest::cleanupTestCase() and 
> KSystemTimeZonesPrivate::setLocalZone() will be uploaded to review board 
> shortly.

Well done, I was really wondering what triggered the issue. This is why I 
didn't commit my fixes yet -- I wanted to write a unittest for them, but didn't 
know what to write in the unittest (all my attempts failed).

Would you be interested in adding a corresponding unittest to reproduceably 
trigger the above issue, and get into an "invalid timezone in a valid 
KDateTime"?

I also wonder if isValid() shouldn't return false, instead, in this particular 
case (invalid timezone offset). That would make more sense I suppose, and then 
my patch to toString() is unnecessary since the method starts with "return 
empty if the datetime is invalid" (which doesn't make debugging any easier, 
though...)

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