For whatever reason, libical doesn't support the Etc/UTC timezone.
Currently we crash gnome-calendar whenever libical doesn't support the
current timezone (as returned by GTimeZone). Let's fall back to UTC
instead.
Fixes#485
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
Most of these are probably paranoid, not bugs. I haven't done an
exhaustive review to see what really needs it: that would be
time-consuming and require significant familiarity with the Calendar
codebase. This was just a quick check. Anyway, I vote for paranoid
when it comes to using g_signal_connect() regardless. It's dangerous,
and there's no reason to ever leave a signal connected after the user
data object has been destroyed.
Fixes#423
This was originally discovered and fixed by Milan Crha; I'm just
forward-porting his fix to the master branch. self->clients takes
ownership of this source but we don't currently have ownership here,
leading to a double free vulnerability.
Fixes#435
Trying to use environment variables to guess the locale was a good
attempt, but this is tricky because they have to be looked up in a
certain order: first LC_ALL, then fallback to LC_TIME, and finally LANG,
which was missed here. This caused a huge warning spam on the year view
when only LANG is set, and usually only LANG should be set since the
other environment variables are usually used for temporary overrides.
Instead, query the locale using setlocale().
Also, don't assert if the locale is shorter than expected (missing
territory code) since there is at least one valid locale that does not
have any territory codes (Esperanto) and since it's programmer error to
assert when the application processes unexpected input like this.
Fixes#424
We fail to disconnect from the GWeatherInfo in both update_location()
and dispose. We have to fix update_location() manually. To avoid the
need to disconnect in dispose, we can just use g_signal_connect_object().
self->weather_service was only partially removed in 01fdf79e6a,
leading to a guaranteed crash when the weather is updated because
self->weather_service is now always NULL.
Fixes#397
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.
The tooltips think all events start and end between 1:00 and 1:59,
because we are missing a % in the format string and the I looks like 1.
I like it when bugs turn out to be easy. Fixes#225.
In month view, when clicking on a day of the month, every event is
initially an All Day event until the user opens the Edit Details dialog
and unchecks the checkbox. This means that the event is originally
created in UTC time, and needs to be explicitly switched to local time.
Michael Catanzaro