When dealing with floating time events the timezone used was UTC,
but according to RFC5545 when the timezone is not specified the
local timezone should be used.
Fixes#171
This patch do not sends ADD_EVENT for events that are multiday and are
part of the old_range when calling calculate_changed_events. This will
prevent multiday duplicate events to appear in the agenda widget when
using the week view.
If the event is a multiday and it was in the previous range, it won't
send the REMOVE_EVENT so multiday events won't dissapear when it's still
relevant.
See https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/898#note_1602391
While fixing timezone bugs, it was found that the calendar property needs
to be set before the component property. The component times may require
to have the calendar set, to be able to lookup the custom timezones in the
calendar, thus make sure the calendar is set before the component is set,
during the construction time.
Rework the initialization process so that setting the construct-only
component property merely takes a hold on the references; and the actual
setting up of the event happens during g_initable_init().
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/788
If we can't find an appropriate timezone, query the ECalClient
for it and give it an extra chance of finding the right timezone.
Thanks to Milan Crha for proposing this fix.
Related: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/444
All-day events always use UTC, so when the multiday detection code was
converting them to the local timezone, they span an additional day if
the local timezone is not the same as UTC. This was leading to all-day
events always being considered multiday events.
Fix this by ignoring the timezone for all-day events, like all other
comparisons do. Also don't consider all-day events spanning 1 day to be
multiday since as per RFC 5545 the end date is non-inclusive and if
omitted to be start + 1 day.
Right now, comparing dates with gcal_date_time_compare_date() gives
the exact opposite result of when comparing using g_date_time_compare().
As shown by this patch, this was a source of *many* bugs.
The return value is nullable, but gnome-calendar fails to check it.
Because the nullable return value is inconvenient for us, we can instead
add and use gcal_context_get_icaltimezone() to supplement the existing
gcal_context_get_timezone().
We'll also need a function to convert from GTimeZone to ICalTimezone,
gcal_timezone_to_icaltimezone().
Fixes#419
