Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QDateTime, issue with addSecs
Forum Updated to NodeBB v4.3 + New Features

QDateTime, issue with addSecs

Scheduled Pinned Locked Moved Solved General and Desktop
9 Posts 5 Posters 1.2k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • U Offline
    U Offline
    Username2
    wrote on last edited by Username2
    #1

    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.

    Issue:
    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
    

    Problem:
    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.

    Resolution:
    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!

    [...]

    aha_1980A J.HilkJ 2 Replies Last reply
    0
    • U Username2

      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.

      Issue:
      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
      

      Problem:
      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.

      Resolution:
      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!

      [...]

      aha_1980A Offline
      aha_1980A Offline
      aha_1980
      Lifetime Qt Champion
      wrote on last edited by
      #2

      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?

      Regards

      Qt has to stay free or it will die.

      U 1 Reply Last reply
      2
      • Kent-DorfmanK Online
        Kent-DorfmanK Online
        Kent-Dorfman
        wrote on last edited by
        #3

        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.

        U 2 Replies Last reply
        3
        • U Username2

          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.

          Issue:
          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
          

          Problem:
          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.

          Resolution:
          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!

          [...]

          J.HilkJ Offline
          J.HilkJ Offline
          J.Hilk
          Moderators
          wrote on last edited by
          #4

          @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

          0_1561697590557_7c0d4761-4409-4b71-a633-cab3bda74282-image.png


          Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


          Q: What's that?
          A: It's blue light.
          Q: What does it do?
          A: It turns blue.

          U 1 Reply Last reply
          1
          • aha_1980A aha_1980

            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?

            Regards

            U Offline
            U Offline
            Username2
            wrote on last edited by
            #5

            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!
            Regards

            1 Reply Last reply
            0
            • Kent-DorfmanK Kent-Dorfman

              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.

              U Offline
              U Offline
              Username2
              wrote on last edited by
              #6

              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.

              mrjjM 1 Reply Last reply
              0
              • U Username2

                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.

                mrjjM Offline
                mrjjM Offline
                mrjj
                Lifetime Qt Champion
                wrote on last edited by
                #7

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

                1 Reply Last reply
                3
                • J.HilkJ J.Hilk

                  @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

                  0_1561697590557_7c0d4761-4409-4b71-a633-cab3bda74282-image.png

                  U Offline
                  U Offline
                  Username2
                  wrote on last edited by
                  #8

                  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.

                  1 Reply Last reply
                  0
                  • Kent-DorfmanK Kent-Dorfman

                    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.

                    U Offline
                    U Offline
                    Username2
                    wrote on last edited by
                    #9

                    @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!

                    1 Reply Last reply
                    3

                    • Login

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • Users
                    • Groups
                    • Search
                    • Get Qt Extensions
                    • Unsolved