https://bugs.kde.org/show_bug.cgi?id=483707
Daniel Vrátil <dvra...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Latest Commit| |https://invent.kde.org/fram
| |eworks/kcalendarcore/-/comm
| |it/f74313db7456f20a16c7a741
| |33218b85b123c093
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
Version Fixed In| |6.1.0
--- Comment #2 from Daniel Vrátil <dvra...@kde.org> ---
Git commit f74313db7456f20a16c7a74133218b85b123c093 by Daniel Vrátil.
Committed on 29/03/2024 at 14:31.
Pushed by cullmann into branch 'master'.
Fix conversion of date-only icaltimetype to UTC QDateTime
The code in readICalDateTime converts the values in icaltimetype structure
to a QDateTime, using the timezone specified in the icaltimetype. If the
icaltimetype is day-only (e.g. in all-day incidence) then it does not
have any timezone information and so Qt::LocalTime is assumed, and a new
QDateTime is constructed that happens on the midnight (beginning) of the
specified day, in user's current local timezone.
In some cases, the function is asked to return the QDateTime in UTC timezone
(for fields that the RFC mandates be always in UTC, like RRULE's UNTIL).
If the user's local timezone is in positive UTC offset, the QDateTime
gets converted to UTC, which shifts those \"all-day\" QDateTimes back
by one day. Later in the code, when it realizes it should be dealing only
with a date, the timezone information is discarded and we end up with a
QDate(Time) that is off by one day compared to what's stored in the iCal data.
This fixes simplifies the handling of day-only icaltimetype and makes sure
to construct the QDateTime already in the correct timezone (i.e. UTC) so
no more conversions are necessary.
FIXED-IN: 6.1.0
M +31 -0 autotests/testicalformat.cpp
M +1 -0 autotests/testicalformat.h
M +4 -4 src/icalformat_p.cpp
https://invent.kde.org/frameworks/kcalendarcore/-/commit/f74313db7456f20a16c7a74133218b85b123c093
--
You are receiving this mail because:
You are watching all bug changes.
