Details
-
Bug
-
Resolution: Invalid
-
Not Evaluated
-
None
-
6.7.3, 6.8.0
-
None
-
Linux Fedora 40
-
Linux/X11
Description
Here is a simple code:
#include <chrono> #include <iostream> #include <QDateTime> #include <QDebug> using namespace std::chrono; typedef std::chrono::milliseconds milliseconds; typedef std::chrono::sys_time<milliseconds> TimeStamp; int main() { const QDateTime& time = QDateTime::fromString("10:44:42:342","hh:mm:ss:zzz"); qDebug() << time; const TimeStamp chrono_time = time.toStdSysMilliseconds(); std::cerr << chrono_time << std::endl; return 0; }
Compiled with:
g++ --std=c++20 -I /usr/include/qt6 -I /usr/include/qt6/QtCore -O4 test.cpp -lQt6Core
It gives:
> ./a.out QDateTime(1900-01-01 10:44:42.342 GMT+1 Qt::LocalTime) 1900-01-01 10:35:21.342
There is a difference of 9min and 21s between the two printed dates.
Digging a bit into the qt sources (with the debugger), I can track down line 369 of localtime.cpp which calculates a result that contains a field tm_gmtoff = 561. This comes directly from the tm linux structure which contains a field:
long tm_gmtoff; /* Seconds East of UTC */
The moral of the story is that computer seems to know my exact longitude and that this correction is applied by the toStdSysMilliseconds() method. Not sure that this is a bug, but if it is the intended behavior, it is one that is very surprising !
Using QTime instead of QDateTime as in the following code, gives a more consistent behavior...
#include <chrono> #include <iostream> #include <QDateTime> #include <QDebug> using namespace std::chrono; typedef std::chrono::milliseconds milliseconds; typedef std::chrono::sys_time<milliseconds> TimeStamp; int main() { const QTime& time = QTime::fromString("10:44:42:342","hh:mm:ss:zzz"); qDebug() << time; const milliseconds duration(time.msecsSinceStartOfDay()); const TimeStamp chrono_time(duration); std::cerr << chrono_time << std::endl; return 0; }
Attachments
Issue Links
- relates to
-
-
- Open
-