Important: Please read the Qt Code of Conduct -

QDateTime, issue with addSecs

  • Thank you to those who have replied and helped to find the issue.

    I'm not sure of the correct format for setting this to solved in this forum, so I'm just editing my original post with the issue and resolution.

    QDateTime QDateTime::addSecs(int) was returning an incorrect QDateTime object based on the QDateTime source object.

    QDateTime currentDT = QDateTime::currentDateTime();
    QDateTime futureDT(currentDT.addSecs(3600));
    qDebug() << "current" << currentDT;
    qDebug() << "future" << futureDT;
    // future date was actually set to a past date, instead of an hour after curretDT as would be expected

    Tracing through the Qt code qdatetime.cpp, I found that there is a call by the QDateTime class to mktime(). It seems that a local library that I was linking in has redefined mktime() and it has a bug that is giving a bad secsSince1970 return value.

    For now I'll be eliminating the erroneous code from the local library and will mark this problem as solved.

    For those interested in the trace to the mktime() call:

    #1  in localToUtc (isdst=1, time=..., date=...) at tools/qdatetime.cpp:4085
    #2  QDateTimePrivate::getUTC (this=<optimized out>, outDate=..., outTime=...) at tools/qdatetime.cpp:4177
    #3  in QDateTimePrivate::addMSecs (dt=..., msecs=3600000) at tools/qdatetime.cpp:2650
    #4  in QDateTime::addSecs (this=<optimized out>, s=<optimized out>) at tools/qdatetime.cpp:2703
    #5  in main () at main.cpp:33

    Again, thanks for your help, and regards!


  • Lifetime Qt Champion

    Hi @Username2,

    Can you check if both time objects have the same timeSpec()?

    I guess problems like yours happen if one time is local and the other UTC, for example. Looking in the documentation, there has been some functions added for timezone handling in Qt 5, so they are not available for you.

    Are you forced to still use Qt 4?


  • very weird.

    I'd need to know more about this other code you are linking in. Could the other library be corrupting the "stack stored" QDateTime objects? Stack corruption is quite common when people use pointers to modify local variables by their address.

  • Moderators

    @Username2 in the case where the time is set to an earlier time, are you sure you add a positive value? Because if you add a negative one, the resulting Qdatetime will have an earlier time


  • Hi @aha_1980 ,
    Thank you for the feedback. I looked over the documentation to verify, and the addSecs() method is supposed to return back a new copied object. I don't think the specs would have changed in the copy. I did some debugging to verify and the spec is the same. I've also updated my original post to include some of the debugging.

    Thank you for your time and help!

  • Hi @Kent-Dorfman ,
    The issues happens when just linking in the library. In the small test code to narrow the issue down, the creation of the currentDT and futureDT object and printing of the objects were done at the start of main before any other calls. After stepping through some of qdatetime.cpp source, you do have me thinking that maybe the problem lies in one of the local header files rather than the library, maybe a typedef or macro being redefined is the culprit here. I'll need to set aside some time to look over the local header files.

    Thank you & regards.

  • Lifetime Qt Champion

    Also look for anything related to timezones and setLocale from the lib you link in.

  • Hi @J.Hilk ,
    Thanks for the feedback. The currentDT does appear to be correct and the integer literal passed to QDateTime::addSecs(int) is a positive value. Just to be sure, I did validate in the debugger that the value passed into the addSecs method wasn't changed. I've added more notes to my original post showing some of my debug session.

    Thank you & regards.

  • @Kent-Dorfman ,
    I've updated the original post with my findings. You were spot on in looking further into the other code linked in. Seems the library I was using had a buggy mktime() method. And the QDateTime class was making use of it to get secs since 1970 which essentially caused the bad results of QDateTime::addSecs().

    Thank you for your help!

Log in to reply