GitLab

This is useful to indicate an asynchronously loaded calendar is still being
filled and thus read access will not return complete (or any) results.

This is something the various Calendar sub-classes in akonadi-calendar
use for example, upstreaming this here will allow to check for this
generically when using the platform calendar plugin interface as well.

QTimeZone::isTimeZoneIdAvailable returns false for UTC offset "timezones"
now, while QTimeZone can nevertheless handle them correctly.

This fixes the testdateserialization unit test with latest Qt 5.15.

Saves one allocation, and allows the removal of the virtual_hook() from
the outside interface as this can now be done via the private class (as
this class hierarchy isn't intended for external extension).

Those are not public API and most of the sub-classes just set them to
a nullptr anyway.

This is essentially the private class of ICalFormat itself, it really
doesn't need any of this indirection.

The current API forces a copy, while most if not all users discard
the unsorted list afterwards anyway and only continue with the sorted
one.

The specific values are the ones documented as defaults already.

This is in line with similar methods for recurrence rules in here.

This is e.g. useful when interfacing with the native Android calendar API,
which is a mix of parsed event properties and partial iCal strings.

This wouldn't hurt much as a regular method, but as a pure virtual one it
just bloats the already massive virtual interface for no good reason.

If `ICalFormat::fromRawString()` processes a component that lacks a
UID property, it creates an instance with an invalid UID, which
violates RFC 5545.

This patch generates a UID from the component's property values, which
will be the same every time it is processed.

BUG: 339726

Glen Ditchfield authored Mar 26, 2022 and Glen Ditchfield committed Mar 26, 2022

CCBUG: 328976

The notebook argument is part of CalFormat API but was not
used in ICalFormat implementation. If set to non empty,
any added incidences when parsing iCal data, are now added
in the given notebook. This enable for instance to get a
list of imported incidences.

Volker Krause authored Mar 06, 2022 and Christoph Cullmann committed Mar 09, 2022

670ebe21 constrained storing timezone information to times with an
explicit time zone, treating times with an UTC offset set as if they would
be local. Using the more detailed UTC check from writeICalDateTime instead
fixes this.

We need a past date here for which addMonths(1) matches what the recurrence
code considers "next month" (which might not be the case towards the end of
the month), and for which addMonths(1) is in the future. The beginning of
the current month satisfies this.

This reverts commit 2814af22.

Add a function to compare two QDateTimes to see if their timeSpecs and
time zones are equal, in addition to the moment in time that they
represent.  Use it to decide whether incidences have been dirtied,
or are equal.

I declared the new `identical()` function in `incidencebase.h` because I 
plan to call it in the incidence editor, and didn't see a better choice
of include file.

I call it in `Period::operator==()`, `Recurrence::Private::operator==()`,
and `RecurrenceRule::Private::operator==()` because as I read the RFC
those datetimes can have time zones or be floating.

`setDtStart()` compares the timeSpecs of the old and new start dates so
that it can distinguish "floating" date-times from date-times with
defined time zones when deciding whether the incidence is dirty.
`setDtDue()` and `setDtEnd()` do likewise.  See commit 322782ce.

For the same reasons, the various `equals()` should also compare
timespecs of those fields.

I also renamed `LOCAL_TZ` because I found it a bit unclear, given that I'm dealing with 
`LocalTime` timespecs and my local timezone isn't Paris.

@dcaliste

An all-day event's dtStart has a timeSpec that is `Qt::LocalTime`, and
in that case `QDateTime::timeZone()` returns whatever the system time
zone is set to.  dtEnd should also be a `LocalTime`, but constructing
it from dtStart's timeZone sets its timeSpec to Qt::`TimeZone`.

@dcaliste  @dfaure

This breaks for dates especially towards the end of January as the
code subsequently calls addMonths(1) on the date. Use a fixed date
instead.

Fixes issues #2.

This reverts commit 47403eb0.

Let the code using OccurrenceIterator deciding how to handle
cancelled occurrences.

That's how they get deserialized again. With Qt5 this was already the case,
with Qt6 container sizes however are 64bit values on 64bit platforms.

Detect changes between "floating" times and times specified to be in the
local time zone.

This completes the trilogy started by commits 9f4628aa and 709b079d.

Commit 795d6c54 was meant to test the changes in commits 709b079d and 9f4628aa.
However, testevent ran using the computer's timezone, so it would only fail the
unpatched code if the test was run on a computer in the Paris timezone.