Details
-
Bug
-
Resolution: Fixed
-
P3: Somewhat important
-
6.8
-
None
-
-
3
-
ef540d777 (dev), e5ab6a658 (6.8)
Description
The problem was first found here: https://forum.qt.io/topic/159844/comparing-sorting-qvariant-in-qt6
After some investigation I found a minimal reproducer and also an explanation:
const auto d1 = QDateTime::currentDateTime(); const auto d2 = d1.addDays(180); // make sure it has not the same DST setting qDebug() << (d1 == d2);
The problem is that 22.11. and 22.11 + 180 days have different DST settings and therefore usesSameOffset() within `bool QDateTime::equals(const QDateTime &other) const` returns false and we've a massive slowdown due to conversion to UTC.
This is due to getStatus() returns 0x8f or 0x4f depending on whether it is inside DST or not.
When I look at the msecs in d->data.msecs I see exactly 180 days difference so the DST flag should not harm here:
((1747853006350-1732301006350)/3600000)/float(24) = 180
Attachments
For Gerrit Dashboard: QTBUG-131491 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
606426,7 | Shortcut QDateTime comparison when difference is large | dev | qt/qtbase | Status: MERGED | +2 | +1 |
607488,2 | Shortcut QDateTime comparison when difference is large | 6.8 | qt/qtbase | Status: MERGED | +2 | 0 |