Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date
All threads index page 4

Qt-interest Archive, May 2007
Maybe a QT 4.2.2 datetime bug


Message 1 in thread

Has anybody had any trouble calculating the difference between 2 times
using the QDateTime class?

The program below returns 1180623600 seconds.  A program I wrote with
python returns 1180627200 seconds.  Notice an hour difference.  When I
calculated by hand I got what python told me.


#include <stdio.h>
#include <QtCore/QDateTime>

int
main(int /*argc*/, char* /*argv*/[])
{
   QDateTime epoch(QDate(1970, 1, 1), QTime(0, 0, 0));
   QDateTime newdate(QDate(2007, 5, 31), QTime(16, 0, 0));
   int seconds = epoch.secsTo(newdate);
   printf("%u seconds\n", seconds);
}

--
 [ signature omitted ] 

Message 2 in thread

Excel gets the same number as your python code :(
 
Im also seeing the bug in 4.2.3
 
Scott

________________________________

From: Jones, Torrin A (US SSA) [mailto:torrin.jones@xxxxxxxxxxxxxx]
Sent: Wed 5/16/2007 3:08 PM
To: qt-interest@xxxxxxxxxxxxx
Subject: Maybe a QT 4.2.2 datetime bug



Has anybody had any trouble calculating the difference between 2 times
using the QDateTime class?

The program below returns 1180623600 seconds.  A program I wrote with
python returns 1180627200 seconds.  Notice an hour difference.  When I
calculated by hand I got what python told me.


#include <stdio.h>
#include <QtCore/QDateTime>

int
main(int /*argc*/, char* /*argv*/[])
{
   QDateTime epoch(QDate(1970, 1, 1), QTime(0, 0, 0));
   QDateTime newdate(QDate(2007, 5, 31), QTime(16, 0, 0));
   int seconds = epoch.secsTo(newdate);
   printf("%u seconds\n", seconds);
}

--
 [ signature omitted ] 

Message 3 in thread

It would be correct if Qt takes into account daylight savings time and
python and Excel do not.

Keith

On 05-16-2007 5:25 PM, "Scott Aron Bloom" wrote:

> Excel gets the same number as your python code :(
>  
> Im also seeing the bug in 4.2.3
>  
> Scott
> 
> ________________________________
> 
> From: Jones, Torrin A (US SSA) [mailto:torrin.jones@xxxxxxxxxxxxxx]
> Sent: Wed 5/16/2007 3:08 PM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: Maybe a QT 4.2.2 datetime bug
> 
> 
> 
> Has anybody had any trouble calculating the difference between 2 times
> using the QDateTime class?
> 
> The program below returns 1180623600 seconds.  A program I wrote with
> python returns 1180627200 seconds.  Notice an hour difference.  When I
> calculated by hand I got what python told me.
> 
> 
> #include <stdio.h>
> #include <QtCore/QDateTime>
> 
> int
> main(int /*argc*/, char* /*argv*/[])
> {
>    QDateTime epoch(QDate(1970, 1, 1), QTime(0, 0, 0));
>    QDateTime newdate(QDate(2007, 5, 31), QTime(16, 0, 0));
>    int seconds = epoch.secsTo(newdate);
>    printf("%u seconds\n", seconds);
> }
> 
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
> 
> 
> 
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
> 

Keith Esau
Senior Software Engineer (dpSHEET)
PDF Solutions, Inc.
keith.esau@xxxxxxx
913-599-6537 (work/home)
913-515-2135 (mobile)
kaesau@xxxxxxxxxxxxx (home/personal)
  
===========================================================================
CONFIDENTIALITY NOTICE: This email contains information that may be
confidential and privileged. Unless you are the intended recipient (or
authorized to receive for the intended recipient), you are prohibited from
reviewing, using, copying, forwarding, keeping, or disclosing to anyone
other than PDF Solutions, Inc. this email or any information in the email
(including any attachment). If you have received this email in error,
please send a reply email only to the sender <keith.esau@xxxxxxx> (delete
the original message body from the reply), and please delete this message
from your system. My apologies for the inconvenience, and thank you in
advance for your cooperation.
===========================================================================


--
 [ signature omitted ] 

Message 4 in thread

After much trial and error, I believe this is definitely an issue.  The
code below returns . . . 

-3599 seconds (QT Version)

I expected . . .

1 seconds (QT Version)

I reported this to the Task Tracker.


#include <stdio.h>
#include <QtCore/QDateTime>

int
main(int /*argc*/, char* /*argv*/[])
{
   QDateTime olddate(QDate(1980, 3, 9), QTime(1, 59, 59));
   QDateTime newdate(QDate(1980, 3, 9), QTime(2, 0, 0));
   int seconds = olddate.secsTo(newdate);
   printf("%d seconds (QT Version)\n", seconds);
}

-----Original Message-----
From: Scott Aron Bloom [mailto:scott@xxxxxxxxxxxx] 
Sent: Wednesday, May 16, 2007 15:25
To: Jones, Torrin A (US SSA); qt-interest@xxxxxxxxxxxxx
Subject: RE: Maybe a QT 4.2.2 datetime bug


Excel gets the same number as your python code :(
 
Im also seeing the bug in 4.2.3
 
Scott

________________________________

From: Jones, Torrin A (US SSA) [mailto:torrin.jones@xxxxxxxxxxxxxx]
Sent: Wed 5/16/2007 3:08 PM
To: qt-interest@xxxxxxxxxxxxx
Subject: Maybe a QT 4.2.2 datetime bug



Has anybody had any trouble calculating the difference between 2 times
using the QDateTime class?

The program below returns 1180623600 seconds.  A program I wrote with
python returns 1180627200 seconds.  Notice an hour difference.  When I
calculated by hand I got what python told me.


#include <stdio.h>
#include <QtCore/QDateTime>

int
main(int /*argc*/, char* /*argv*/[])
{
   QDateTime epoch(QDate(1970, 1, 1), QTime(0, 0, 0));
   QDateTime newdate(QDate(2007, 5, 31), QTime(16, 0, 0));
   int seconds = epoch.secsTo(newdate);
   printf("%u seconds\n", seconds);
}

--
 [ signature omitted ] 

Message 5 in thread

Keith has it right...
 
Your calling it with the timespec set to local time (default third parameter), which of course will use timezones and daylight savings time...
enum Qt::TimeSpec
Qt::LocalTime	 0	 Locale dependent time (Timezones and Daylight Savings Time).	
Qt::UTC	 1	 Coordinated Universal Time, replaces Greenwich Mean Time.	

 
Call it as such
QDateTime olddate(QDate(1980, 3, 9), QTime(1, 59, 59), Qt::UTC);

QDateTime newdate(QDate(1980, 3, 9), QTime(2, 0, 0), Qt::UTC);

int seconds = olddate.secsTo(newdate);

 

And you get the results your expecting...

 

Scott

________________________________

From: Jones, Torrin A (US SSA) [mailto:torrin.jones@xxxxxxxxxxxxxx]
Sent: Wed 5/16/2007 3:53 PM
To: qt-interest@xxxxxxxxxxxxx
Subject: RE: Maybe a QT 4.2.2 datetime bug



After much trial and error, I believe this is definitely an issue.  The
code below returns . . .

-3599 seconds (QT Version)

I expected . . .

1 seconds (QT Version)

I reported this to the Task Tracker.


#include <stdio.h>
#include <QtCore/QDateTime>

int
main(int /*argc*/, char* /*argv*/[])
{
   QDateTime olddate(QDate(1980, 3, 9), QTime(1, 59, 59));
   QDateTime newdate(QDate(1980, 3, 9), QTime(2, 0, 0));
   int seconds = olddate.secsTo(newdate);
   printf("%d seconds (QT Version)\n", seconds);
}

-----Original Message-----
From: Scott Aron Bloom [mailto:scott@xxxxxxxxxxxx]
Sent: Wednesday, May 16, 2007 15:25
To: Jones, Torrin A (US SSA); qt-interest@xxxxxxxxxxxxx
Subject: RE: Maybe a QT 4.2.2 datetime bug


Excel gets the same number as your python code :(

Im also seeing the bug in 4.2.3

Scott

________________________________

From: Jones, Torrin A (US SSA) [mailto:torrin.jones@xxxxxxxxxxxxxx]
Sent: Wed 5/16/2007 3:08 PM
To: qt-interest@xxxxxxxxxxxxx
Subject: Maybe a QT 4.2.2 datetime bug



Has anybody had any trouble calculating the difference between 2 times
using the QDateTime class?

The program below returns 1180623600 seconds.  A program I wrote with
python returns 1180627200 seconds.  Notice an hour difference.  When I
calculated by hand I got what python told me.


#include <stdio.h>
#include <QtCore/QDateTime>

int
main(int /*argc*/, char* /*argv*/[])
{
   QDateTime epoch(QDate(1970, 1, 1), QTime(0, 0, 0));
   QDateTime newdate(QDate(2007, 5, 31), QTime(16, 0, 0));
   int seconds = epoch.secsTo(newdate);
   printf("%u seconds\n", seconds);
}

--
 [ signature omitted ] 

Message 6 in thread

On 16.05.07 15:53:59, Jones, Torrin A (US SSA) wrote:
> After much trial and error, I believe this is definitely an issue.  The
> code below returns . . . 
> 
> -3599 seconds (QT Version)
> 
> I expected . . .
> 
> 1 seconds (QT Version)
> 
> I reported this to the Task Tracker.
> 
> 
> #include <stdio.h>
> #include <QtCore/QDateTime>
> 
> int
> main(int /*argc*/, char* /*argv*/[])
> {
>    QDateTime olddate(QDate(1980, 3, 9), QTime(1, 59, 59));
>    QDateTime newdate(QDate(1980, 3, 9), QTime(2, 0, 0));
>    int seconds = olddate.secsTo(newdate);
>    printf("%d seconds (QT Version)\n", seconds);
> }

For me this returns exactly 1 second, I'm using Qt4.3rc1 (more or less).

And for your original example I get the same value as you got with Qt, I
guess Keith may be right and Qt takes daylight savings into account.

Andreas

-- 
 [ signature omitted ] 

Message 7 in thread

Yes, this gets me what I expected.  However shouldn't you always get 1
second out it when you calculate the difference between the 2 dates
below using the same Qt::TimeSpec?  Secondly, according to
http://webexhibits.org/daylightsaving/b.html, Daylight Saving Time began
on April 6, 1980 in the United States.  So it would seem to me, that it
wouldn't be a factor in calculating the difference in the current locale
on March 9, 1980.  I guess it doesn't matter since using Qt::UTC solved
that problem.  Also according to another E-mail of the list, 4.3rc1
fixes this.

So I guess the moral, is use care when you're calculating the difference
between 2 QDateTime values.

Thanks for the help.

-----Original Message-----
From: Scott Aron Bloom [mailto:scott@xxxxxxxxxxxx] 
Sent: Wednesday, May 16, 2007 16:19
To: Jones, Torrin A (US SSA); qt-interest@xxxxxxxxxxxxx
Subject: RE: Maybe a QT 4.2.2 datetime bug


Keith has it right...
 
Your calling it with the timespec set to local time (default third
parameter), which of course will use timezones and daylight savings
time...
enum Qt::TimeSpec
Qt::LocalTime	 0	 Locale dependent time (Timezones and Daylight
Savings Time).	
Qt::UTC	 1	 Coordinated Universal Time, replaces Greenwich Mean
Time.	

 
Call it as such
QDateTime olddate(QDate(1980, 3, 9), QTime(1, 59, 59), Qt::UTC);

QDateTime newdate(QDate(1980, 3, 9), QTime(2, 0, 0), Qt::UTC);

int seconds = olddate.secsTo(newdate);

 

And you get the results your expecting...

 

Scott

________________________________

From: Jones, Torrin A (US SSA) [mailto:torrin.jones@xxxxxxxxxxxxxx]
Sent: Wed 5/16/2007 3:53 PM
To: qt-interest@xxxxxxxxxxxxx
Subject: RE: Maybe a QT 4.2.2 datetime bug



After much trial and error, I believe this is definitely an issue.  The
code below returns . . .

-3599 seconds (QT Version)

I expected . . .

1 seconds (QT Version)

I reported this to the Task Tracker.


#include <stdio.h>
#include <QtCore/QDateTime>

int
main(int /*argc*/, char* /*argv*/[])
{
   QDateTime olddate(QDate(1980, 3, 9), QTime(1, 59, 59));
   QDateTime newdate(QDate(1980, 3, 9), QTime(2, 0, 0));
   int seconds = olddate.secsTo(newdate);
   printf("%d seconds (QT Version)\n", seconds);
}

-----Original Message-----
From: Scott Aron Bloom [mailto:scott@xxxxxxxxxxxx]
Sent: Wednesday, May 16, 2007 15:25
To: Jones, Torrin A (US SSA); qt-interest@xxxxxxxxxxxxx
Subject: RE: Maybe a QT 4.2.2 datetime bug


Excel gets the same number as your python code :(

Im also seeing the bug in 4.2.3

Scott

________________________________

From: Jones, Torrin A (US SSA) [mailto:torrin.jones@xxxxxxxxxxxxxx]
Sent: Wed 5/16/2007 3:08 PM
To: qt-interest@xxxxxxxxxxxxx
Subject: Maybe a QT 4.2.2 datetime bug



Has anybody had any trouble calculating the difference between 2 times
using the QDateTime class?

The program below returns 1180623600 seconds.  A program I wrote with
python returns 1180627200 seconds.  Notice an hour difference.  When I
calculated by hand I got what python told me.


#include <stdio.h>
#include <QtCore/QDateTime>

int
main(int /*argc*/, char* /*argv*/[])
{
   QDateTime epoch(QDate(1970, 1, 1), QTime(0, 0, 0));
   QDateTime newdate(QDate(2007, 5, 31), QTime(16, 0, 0));
   int seconds = epoch.secsTo(newdate);
   printf("%u seconds\n", seconds);
}

--
 [ signature omitted ] 

Message 8 in thread

The change in Daylight Savings time is worse than the year 2000 problem.
Under the current DST calculations, March 9, 1980 2:00am never happened.
March 9, 1980 would have been the date 2:00am jumps to 3:00am. IOW,
1:59:59am + 1 second = 3:00:00am.

Of course, DST changed at a different time back then. IMHO, dates should
always be stored (and calculated) as UTC and only displayed in local time to
prevent problems like this.

A bigger problem happens with 1:30am in the fall. Which 1:30am are you
referring to? The one before the clocks are turned back (from 2am to 1am) or
the one after? How do you specify that in Qt? The only way I can find is to
use UTC.

Keith

On 05-17-2007 10:35 AM, "Jones, Torrin A (US SSA)" wrote:

> Yes, this gets me what I expected.  However shouldn't you always get 1
> second out it when you calculate the difference between the 2 dates
> below using the same Qt::TimeSpec?  Secondly, according to
> http://webexhibits.org/daylightsaving/b.html, Daylight Saving Time began
> on April 6, 1980 in the United States.  So it would seem to me, that it
> wouldn't be a factor in calculating the difference in the current locale
> on March 9, 1980.  I guess it doesn't matter since using Qt::UTC solved
> that problem.  Also according to another E-mail of the list, 4.3rc1
> fixes this.
> 
> So I guess the moral, is use care when you're calculating the difference
> between 2 QDateTime values.
> 
> Thanks for the help.
> 
> -----Original Message-----
> From: Scott Aron Bloom [mailto:scott@xxxxxxxxxxxx]
> Sent: Wednesday, May 16, 2007 16:19
> To: Jones, Torrin A (US SSA); qt-interest@xxxxxxxxxxxxx
> Subject: RE: Maybe a QT 4.2.2 datetime bug
> 
> 
> Keith has it right...
>  
> Your calling it with the timespec set to local time (default third
> parameter), which of course will use timezones and daylight savings
> time...
> enum Qt::TimeSpec
> Qt::LocalTime  0  Locale dependent time (Timezones and Daylight
> Savings Time). 
> Qt::UTC  1  Coordinated Universal Time, replaces Greenwich Mean
> Time. 
> 
>  
> Call it as such
> QDateTime olddate(QDate(1980, 3, 9), QTime(1, 59, 59), Qt::UTC);
> 
> QDateTime newdate(QDate(1980, 3, 9), QTime(2, 0, 0), Qt::UTC);
> 
> int seconds = olddate.secsTo(newdate);
> 
>  
> 
> And you get the results your expecting...
> 
>  
> 
> Scott
> 
> ________________________________
> 
> From: Jones, Torrin A (US SSA) [mailto:torrin.jones@xxxxxxxxxxxxxx]
> Sent: Wed 5/16/2007 3:53 PM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: RE: Maybe a QT 4.2.2 datetime bug
> 
> 
> 
> After much trial and error, I believe this is definitely an issue.  The
> code below returns . . .
> 
> -3599 seconds (QT Version)
> 
> I expected . . .
> 
> 1 seconds (QT Version)
> 
> I reported this to the Task Tracker.
> 
> 
> #include <stdio.h>
> #include <QtCore/QDateTime>
> 
> int
> main(int /*argc*/, char* /*argv*/[])
> {
>    QDateTime olddate(QDate(1980, 3, 9), QTime(1, 59, 59));
>    QDateTime newdate(QDate(1980, 3, 9), QTime(2, 0, 0));
>    int seconds = olddate.secsTo(newdate);
>    printf("%d seconds (QT Version)\n", seconds);
> }
> 
> -----Original Message-----
> From: Scott Aron Bloom [mailto:scott@xxxxxxxxxxxx]
> Sent: Wednesday, May 16, 2007 15:25
> To: Jones, Torrin A (US SSA); qt-interest@xxxxxxxxxxxxx
> Subject: RE: Maybe a QT 4.2.2 datetime bug
> 
> 
> Excel gets the same number as your python code :(
> 
> Im also seeing the bug in 4.2.3
> 
> Scott
> 
> ________________________________
> 
> From: Jones, Torrin A (US SSA) [mailto:torrin.jones@xxxxxxxxxxxxxx]
> Sent: Wed 5/16/2007 3:08 PM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: Maybe a QT 4.2.2 datetime bug
> 
> 
> 
> Has anybody had any trouble calculating the difference between 2 times
> using the QDateTime class?
> 
> The program below returns 1180623600 seconds.  A program I wrote with
> python returns 1180627200 seconds.  Notice an hour difference.  When I
> calculated by hand I got what python told me.
> 
> 
> #include <stdio.h>
> #include <QtCore/QDateTime>
> 
> int
> main(int /*argc*/, char* /*argv*/[])
> {
>    QDateTime epoch(QDate(1970, 1, 1), QTime(0, 0, 0));
>    QDateTime newdate(QDate(2007, 5, 31), QTime(16, 0, 0));
>    int seconds = epoch.secsTo(newdate);
>    printf("%u seconds\n", seconds);
> }


--
 [ signature omitted ] 

Message 9 in thread

On Thursday 17 May 2007 18:56, Keith Esau wrote:
> A bigger problem happens with 1:30am in the fall. Which 1:30am are you
> referring to? The one before the clocks are turned back (from 2am to 1am)
> or the one after? How do you specify that in Qt? The only way I can find is
> to use UTC.

You have to be very carefull here.
If two datetimes are set right after the fall shift (>2am), and you substract 
a value less than an hour so that it results to 1:30am, the value referes to 
the 1:30am post shift.
If you have substracted a value > 1h (so it results to before 1:00am) and then 
add an amount that results to 1:30, it will be the 1:30 pre shift.

This causes real trouble if used in a GUI where users enter timestamps 
manually.
QDateTimeEdit cannot handle this - as it must be localized at that point.

Frank

--
 [ signature omitted ]