Loading...

XML

Word

Printable

Details

Type: Bug
Resolution: Out of scope
Priority: P2: Important
Fix Version/s: None
Affects Version/s: 5.15.8
Component/s: Core: Date/Time
Labels:
- Reported_by_support_standard

Platform/s:

Android
Commits:
0959023d1c (qt/tqtc-qtbase/5.15)
Sprint:
Team A Foundation Sprint 55, Foundation PM Staging

Description

When using QDateTime with Qt::LocalTime instead of a set timezone, adding days to it with addDays() and comparing to a QDateTime that has timezone "Asia/Tehran" set, daylights savings is not handled properly and leads to an invalid QDateTime object. The android device needs to have Asia/Tehran set as a system timezone.

This works properly with desktop kit, and seems to have already been fixed in Qt 6.2.

Log of working situation:

D libuntitled11_armeabi-v7a.so: Start min= QTimeZone("Asia/Tehran") , max= QTimeZone("Asia/Tehran")
D libuntitled11_armeabi-v7a.so: QDateTime(2022-03-17 00:00:00.000 GMT+03:30 Qt::TimeZone Asia/Tehran )  isValid= true
D libuntitled11_armeabi-v7a.so: QDateTime(2022-03-18 00:00:00.000 GMT+03:30 Qt::TimeZone Asia/Tehran )  isValid= true
D libuntitled11_armeabi-v7a.so: QDateTime(2022-03-19 00:00:00.000 GMT+03:30 Qt::TimeZone Asia/Tehran )  isValid= true
D libuntitled11_armeabi-v7a.so: QDateTime(2022-03-20 00:00:00.000 GMT+03:30 Qt::TimeZone Asia/Tehran )  isValid= true
D libuntitled11_armeabi-v7a.so: QDateTime(2022-03-21 00:00:00.000 GMT+03:30 Qt::TimeZone Asia/Tehran )  isValid= true
D libuntitled11_armeabi-v7a.so: QDateTime(2022-03-22 01:00:00.000 GMT+04:30 Qt::TimeZone Asia/Tehran )  isValid= true <--- Daylight savings changes
D libuntitled11_armeabi-v7a.so: QDateTime(2022-03-23 01:00:00.000 GMT+04:30 Qt::TimeZone Asia/Tehran )  isValid= true
D libuntitled11_armeabi-v7a.so: QDateTime(2022-03-24 01:00:00.000 GMT+04:30 Qt::TimeZone Asia/Tehran )  isValid= true

And log of broken situation:

D libuntitled11_armeabi-v7a.so: Start min= QTimeZone("Asia/Tehran") , max= QTimeZone("Asia/Tehran")
D libuntitled11_armeabi-v7a.so: QDateTime(2022-03-17 00:00:00.000 +0330 Qt::LocalTime)  isValid= true
D libuntitled11_armeabi-v7a.so: QDateTime(2022-03-18 00:00:00.000 +0330 Qt::LocalTime)  isValid= true
D libuntitled11_armeabi-v7a.so: QDateTime(2022-03-19 00:00:00.000 +0330 Qt::LocalTime)  isValid= true
D libuntitled11_armeabi-v7a.so: QDateTime(2022-03-20 00:00:00.000 +0330 Qt::LocalTime)  isValid= true
D libuntitled11_armeabi-v7a.so: QDateTime(2022-03-21 00:00:00.000 +0330 Qt::LocalTime)  isValid= true
D libuntitled11_armeabi-v7a.so: QDateTime(Invalid)  isValid= false
D libuntitled11_armeabi-v7a.so: QDateTime(-4714-11-24 00:00:00.000 +0330 Qt::LocalTime)  isValid= true
D libuntitled11_armeabi-v7a.so: QDateTime(-4714-11-25 00:00:00.000 +0330 Qt::LocalTime)  isValid= true
D libuntitled11_armeabi-v7a.so: QDateTime(-4714-11-26 00:00:00.000 +0330 Qt::LocalTime)  isValid= true

If the QDateTime object that is using Qt::LocalTime instead has "Asia/Tehran" timezone set, it works properly. At least Europe/Helsinki timezone does not show this same issue.

Working situation with Europe/Helsinki timezone that observed daylights saving a bit later (27th). In this case the 1 hour is not added by the addDays like it is in Asia/Tehran use case:

D libqtbug102109_armeabi-v7a.so: Start min= QTimeZone("Europe/Helsinki") , max= QTimeZone("Europe/Helsinki")
D libqtbug102109_armeabi-v7a.so: QDateTime(2022-03-25 00:00:00.000 EET Qt::LocalTime)  isValid= true
D libqtbug102109_armeabi-v7a.so: QDateTime(2022-03-26 00:00:00.000 EET Qt::LocalTime)  isValid= true
D libqtbug102109_armeabi-v7a.so: QDateTime(2022-03-27 00:00:00.000 EET Qt::LocalTime)  isValid= true
D libqtbug102109_armeabi-v7a.so: QDateTime(2022-03-28 00:00:00.000 EEST Qt::LocalTime)  isValid= true
D libqtbug102109_armeabi-v7a.so: QDateTime(2022-03-29 00:00:00.000 EEST Qt::LocalTime)  isValid= true
D libqtbug102109_armeabi-v7a.so: QDateTime(2022-03-30 00:00:00.000 EEST Qt::LocalTime)  isValid= true