Editing an event from Google Calendar changes the time by the UTC offset

[cassidyjames]

What Happened

I had a calendar event for 2 PM MST (UTC-7). I open it to edit, and the edit dialog still shows 2 PM. I changed the event from one day to another, leaving the time set to 2 PM. When I save the event, Calendar saves it in UTC (therefor changing it by the UTC offset, so 2 PM UTC = 7 AM MST) instead of the original/current time zone.

Expected Behavior

Calendar would retain the timezone, and likely show the time zone any time a time is shown for clarity.

Steps to Reproduce

1. Create a calendar event in Google Calendar with a timezone associated
2. Edit the event in elementary Calendar, e.g. changing the date but not the time
3. See that the time is changed by the UTC offset

Platform Information

elementary OS 6 Early Access with Calendar from master

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[mcclurgm]

Is this Google calendar only? I only have local accounts on my beta VM, but there it doesn't move the time. It does remove the time zone (makes it "floating"), so it appears at the proper time in my current time zone.

If so, a guess for why this is happening. I don't think Google supports floating time zones. So when we upload an event with a floating time zone, Google interprets it as UTC then that causes the issue. I'll look a little closer on my Hera install that has my Google accounts, I don't think any of this should have changed since we broke compatibility.

The floating time zone issue is bad news and extends beyond Google too. Floating events occur at the same time of day in every time zone. So for any event we save through Calendar, an 8:30 AM event you saved in Denver will also happen at 8:30 AM if you moved to London. Looks like we're messing up people's data every time they edit an event. Oops…

At least if we're going to break the original time zone, we should associate it with the computer's local time zone to not break things. That would break actual floating events, but those are rare and most calendar clients don't support them AFAIK.

[cassidyjames]

@mcclurgm yes, for me I tested a locally-created event and could not reproduce this issue, but can reliably reproduce it with an event created from Google Calendar and then modified in elementary Calendar. Removing the timezone seems like a big no-no here, especially if you're trying to coordinate calendars with anyone in another timezone. 😛

But yeah, I think we should explicitly display the timezone in the edit dialog, and ensure we're both loading and saving the correct timezone (or yeah, possibly defaulting to the user's timezone if none is set).

[mcclurgm]

Sounds good. I'll see what I can do. We'll need some design work on how to display the time zone.

• Do we always display the time zone, or only when it's not the current one?
• Should we make it collapsible? (Some other clients do this, since it's sort of an advanced feature)
• Do we display the local time zone info too, or just in the event time zone?
• What format should it be? I can think of making it a Label that just says the name (like America / Denver), but that seems awful drab in a way.
• How do we display floating time zones? (I feel like it's a sort of complicated thing to describe concisely in a status label)

Here's an absolute bare minimum of what we could do:

If we're doing time zones read-only, then we don't need to think too hard about the floating case. I think I fixed that a few months back. If we ever want to make this editable, then it'll take some work to deal with edge cases, like what you saw when we try to assign a floating time zone to a Google event.

In the meantime, I can get working on preserving the time zone. (Who came up with this time zone thing? They're a pain to deal with 😜️)

[mcclurgm]

I've tracked down the issue that causes us to set a floating timezone (this is a real bug, not unimplemented case, in Util.datetimes_to_icaltime). Fixing it now, but I have a scope question. Do we want to support floating timezones at all, in either the backend or front end? The current implementation won't support null timezones, so I'll have to do a little more work to add that. I'm leaning toward implementing that now, while I'm changing the function anyway, but would like to hear your thoughts.

[cassidyjames]

@mcclurgm sorry for taking so long to get back to you here. If the question is still outstanding: I'm not sure. 😅 I think it would be fine to not support floating timezones and to just default to the current user's timezone when creating or editing an event if the timezone is null. I guess the bigger question for me is how other popular calendars handle that case, e.g. in Google Calendar or the iOS calendar app.

[mcclurgm]

I think I just forged ahead using an answer I made up myself 😬... I think it makes sense to use floating time zones. That brings us closer to libical, especially with all-day events, which are defined as floating in the spec and library. (This is a little complicated with GLib.DateTime, which doesn't have the concept of floating times, though. Hence #675.) And if we do wind up using #675, then we basically get them for free by using a library that supports them.

Does that make sense to you?

As for prior art, I'm pretty sure that Google doesn't support them, while iOS and Fantastical both do. Those are the only calendar apps I really use myself.

[cassidyjames]

@mcclurgm ah that's right, all-day events. Yeah to me it makes sense then to get closer to libical. I'm not as familiar with the implementation at all but you've convinced me, at least. 😉