Checking if an event is multiday is currently broken
because g_date_time_difference() returns raw time spans,
and that value means "there is 24h of difference between
these dates", when what we're looking for is "how many
days are between these two dates".
To fix that, use the GDate API instead of GDateTime.
The old code here was not setting tzid correctly. It me took hours to
figure out how to do this, but it turned out to be simple once I found
the right place, buried deep in the e-d-s source code.
Now, ideally we would not change the timezone of the event every time we
edit it. But some big changes in how GNOME Calendar tracks timezone are
going to be required if we do that. In particular, I believe we would
have to stop saving all day events in UTC, and give up on using
GDateTime as we do now, and track timezone completely separately
everywhere using icaltimezone. This is what e-d-s does, and it's
probably what we should be doing too. But that would be a big change.
This commit solves the basic problem, which is to ensure the event is
scheduled for the right time, regardless of timezone.
This finally completely fixes#168.
This reverts commit ce2c955269.
This commit is not right. Lots of code in Calendar relies on being able
to set the timezone of a GcalEvent, and this results in us always
ignoring the timezone set by Calendar in preference to whatever happened
to be in the ECalComponentDateTime previously. That might not be so bad,
but additionally, the time is not adjusted accordingly, so this actually
results in the time of events changing unexpectedly from what Calendar
is trying to set.
The code to explicitly store UTC times for all day events is OK (I
guess) and will be restored in a subsequent commit.
g_date_time_equal() corrects for timezone offsets to ensure that, e.g.,
6 AM CST is treated as equal to 12 PM UTC. This means attempts to change
the start and end times of events to the same time in another timezone
are currently failing. We need to remove this attempt at optimization
because it prevents gcal_event_set_timezone() from ever doing anything.
Earlier, an event had no recurrence property. Hence, the event's
recurrence pattern etc. could not be analysed, and as a result
could not be changed by the user. gnome-calendar just displayed
all the recurrences of a recurring event but had no 'readable'
knowledge regarding the characteristics of those recurrences.
This patch adds the recurrence property, which is basically
a GcalRecurrence structure linked to the event.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
23,776 bytes in 743 blocks are definitely lost in loss record 19,053 of 19,159
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0x9A0C90E: g_malloc (gmem.c:94)
by 0x9A26A55: g_slice_alloc (gslice.c:1025)
by 0x9A26AD7: g_slice_copy (gslice.c:1076)
by 0x6A97912: gdk_rgba_copy (gdkrgba.c:76)
by 0x42B35E: gcal_event_set_color (gcal-event.c:750)
by 0x42BF3E: gcal_event_set_source (gcal-event.c:1204)
by 0x42AE20: gcal_event_set_property (gcal-event.c:481)
by 0x956B39B: object_set_property (gobject.c:1423)
by 0x956BFDF: g_object_new_internal (gobject.c:1817)
by 0x956CB24: g_object_new_valist (gobject.c:2042)
by 0x878945D: g_initable_new_valist (ginitable.c:224)
https://bugzilla.gnome.org/show_bug.cgi?id=772272
28,337 bytes in 415 blocks are definitely lost in loss record 18,432 of 18,507
at 0x4C2FC47: realloc (vg_replace_malloc.c:785)
by 0xA88021D: vasprintf (in /usr/lib64/libc-2.24.so)
by 0x9A593FC: g_vasprintf (gprintf.c:316)
by 0x9A292F7: g_strdup_vprintf (gstrfuncs.c:514)
by 0x9A2939C: g_strdup_printf (gstrfuncs.c:540)
by 0x42A10B: gcal_event_update_uid_internal (gcal-event.c:192)
by 0x42BF52: gcal_event_set_source (gcal-event.c:1217)
by 0x42ADCA: gcal_event_set_property (gcal-event.c:480)
by 0x956B39B: object_set_property (gobject.c:1423)
by 0x956BFDF: g_object_new_internal (gobject.c:1817)
by 0x956CB24: g_object_new_valist (gobject.c:2042)
by 0x878945D: g_initable_new_valist (ginitable.c:224)
https://bugzilla.gnome.org/show_bug.cgi?id=772272
29,717 (8,128 direct, 21,589 indirect) bytes in 508 blocks are definitely lost in loss record 18,380 of 18,445
at 0x4C2FA50: calloc (vg_replace_malloc.c:711)
by 0x9A0C981: g_malloc0 (gmem.c:124)
by 0x9A0CC64: g_malloc0_n (gmem.c:355)
by 0x5BE3948: e_cal_component_get_id (e-cal-component.c:1477)
by 0x42A06D: gcal_event_update_uid_internal (gcal-event.c:178)
by 0x42A64D: gcal_event_set_component_internal (gcal-event.c:310)
by 0x42AD0F: gcal_event_set_property (gcal-event.c:459)
by 0x956B39B: object_set_property (gobject.c:1423)
by 0x956BFDF: g_object_new_internal (gobject.c:1817)
by 0x956CB24: g_object_new_valist (gobject.c:2042)
by 0x878945D: g_initable_new_valist (ginitable.c:224)
by 0x878933A: g_initable_new (ginitable.c:146)
https://bugzilla.gnome.org/show_bug.cgi?id=772272
105,858 (42,064 direct, 63,794 indirect) bytes in 478 blocks are definitely lost in loss record 19,065 of 19,103
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0x9A0C90E: g_malloc (gmem.c:94)
by 0x9A26A55: g_slice_alloc (gslice.c:1025)
by 0x99F0510: g_hash_table_new_full (ghash.c:711)
by 0x42B10C: gcal_event_init (gcal-event.c:657)
by 0x9584B32: g_type_create_instance (gtype.c:1866)
by 0x956BED0: g_object_new_internal (gobject.c:1783)
by 0x956CB24: g_object_new_valist (gobject.c:2042)
by 0x878945D: g_initable_new_valist (ginitable.c:224)
by 0x878933A: g_initable_new (ginitable.c:146)
by 0x42B181: gcal_event_new (gcal-event.c:690)
by 0x4549CA: gcal_year_view_component_added (gcal-year-view.c:1632)
https://bugzilla.gnome.org/show_bug.cgi?id=772272
Previously we were synthesising an end date of "start + 1 day", but this
isn't necessary. RFC 2445 tells us that no end date already means an all
day event.
Check this case directly.
https://bugzilla.gnome.org/show_bug.cgi?id=762985
In this commit, we fixed a crash report that occurred when an event had no end date.
Events with no end dates are all-day, 1-day length events. But, when an event with no end date set was synchronized with calendar (happened mostly with birthdays), it caused crashes, because the function responsible for getting the end date received NULL.
To correct this, we considered that end = start + 1day when no end date is set. With this, the mistake was corrected. Another thing that was correct along with this were two memory leaks, caused by the allocation of both end and start date that were not been freed.
https://bugzilla.gnome.org/show_bug.cgi?id=762985
tzid can have different formats depending on where it originates from:
regular or prefixed by a libical specific identifier. Use the
right icaltimezone_get_builtin_timezone* for each case.
https://bugzilla.gnome.org/show_bug.cgi?id=763180
I don't know the reasoning behind it, but sometimes
I see dates like March 32 or February 30. Events are
correctly added, so I suspect it's an issue with another
app.
In any case, we should be able to handle weird dates
without crashing, so normalize the dates before using
them.
Using libical with libecal means that the dates
are always stored as UTF dates, and we receive the
timezone as the ECalComponentDateTime::tzid value.
This fact was net being considered when adding date
support on GcalEvent, and was causing various issues
when displaying dates.
Fix that by properly handling timezones in GcalEvent.
