Workaround for broken QDateTime::secsTo or QDateTime::addSecs (at least in Qt 3.3). While QDateTime::secsTo does take time zones into account, QDateTime::addSecs does not, so we have a problem:
Workaround for broken QDateTime::secsTo or QDateTime::addSecs (at least in Qt 3.3). While QDateTime::secsTo does take time zones into account, QDateTime::addSecs does not, so we have a problem:

      QDateTime d1(QDate(2005, 10, 30), QTime(1, 30, 0) );
      QDateTime d2(QDate(2005, 10, 30), QTime(3, 30, 0) );

      kdDebug(5800) << "d1=" << d1 << ", d2=" << d2 << endl;
      kdDebug(5800) << "d1.secsTo(d2)=" << d1.secsTo(d2) << endl;
      kdDebug(5800) << "d1.addSecs(d1.secsTo(d2))=" << d1.addSecs(d1.secsTo(d2)) << endl;

This code generates the following output:

      libkcal: d1=Son Okt 30 01:30:00 2005, d2=Son Okt 30 03:30:00 2005
      libkcal: d1.secsTo(d2)=10800
      libkcal: d1.addSecs(d1.secsTo(d2))=Son Okt 30 04:30:00 2005

Notice that secsTo counts the hour between 2:00 and 3:00 twice, while adddSecs doesn't and so has one additional hour. As a result, d1.addSecs(d1.secsTo(d2)),  which should always return exactly d2, is one hour off! 
This basically makes it impossible to use QDateTime for *any* calculations, in local time zone as well as in UTC. Since we don't want to use time zones anyway, but do all secondsly/minutely/hourly calculations in UTC, we simply use our own secsTo, which ignores all time zone shifts.


svn path=/trunk/KDE/kdepim/; revision=422282

lefou/kdepim-noakonadi,lefou/kdepim-noakonadi,lefou/kdepim-noakonadi,lefou/kdepim-noakonadi,lefou/kdepim-noakonadi,lefou/kdepim-noakonadi