Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calendar sync doesn't take into account timezones of event on calendar #3678

Open
Fireprufe15 opened this issue Nov 12, 2024 · 4 comments
Open

Comments

@Fireprufe15
Copy link

Your Environment

  • Version used: 10.1.1 - Android (running in Chromebook Android app support)
  • Operating System and version: ChromeOS 130.0.6723.84 64-bit

Expected Behavior

If importing calendar events from ICS that have a specific timezone associated, they should be adjusted to my timezone for locally scheduled events.

Current Behavior

Events that are scheduled for example on 13:00 in the UTC+1 timezone, show up as 13:00 in planner and schedule, but my local device's time zone is UTC+2, so the event should be showing up as 14:00.

Steps to Reproduce (for bugs)

  1. Get the ICS link for a calendar that has events on a different timezone than your own
  2. Connect this calendar with the regular steps for connecting a calendar
  3. Once it has synced, look at Planner to see when the events are scheduled.
  4. Notice that events are scheduled in the timezone they were created in and not adjusted for local timezone

Can you reproduce this reliably?

I can reproduce reliably on my device. Have also tried on a Windows machine with the desktop client, and the same issue appears here.
The calendars I've tested this with are from Outlook, not sure if it happens with other calendar providers.

Copy link

Thank you very much for opening up this issue! I am currently a bit overwhelmed by the many requests that arrive each week, so please forgive me, if I fail to respond personally. I am still very likely to at least skim read your request and I'll probably try to fix all (real) bugs if possible and I will likely review every single PR being made (please, give me a heads up if you intent to do so) and I will try to work on popular requests (please upvote via thumbs up on the original issue) whenever possible, but trying to respond to every single issue over the last years has been kind of draining and I need to adjust my approach for this project to remain fun for me and to make any progress with actually coding new stuff. Thanks for your understanding!

Copy link

Hello there Fireprufe15! 👋

Thank you and congratulations 🎉 for opening your very first issue in this project! 💖

In case you want to claim this issue, please comment down below! We will try to get back to you as soon as we can. 👀

For more open ended discussions and/or specific questions, please visit the discussions page. 💖

@Fireprufe15
Copy link
Author

I've done some further investigation, it seems to not be ALL events coming from ICAL that have this problem, so I'm guessing rather than it being a problem in the code per se, it is something weird that certain events (specifically, recurring events) do in the ICAL response.

And it seems to mostly happen with events from an Outlook/Exchange calendar. I haven't been able to replicate it with, for example, a Google Calendar.

Would it be helpful to have a sample ICAL response from the calendar that does show this issue?

@Fireprufe15
Copy link
Author

Fireprufe15 commented Nov 17, 2024

Looking into the events that cause the issue:

When logging the output of recur.iterator(start) , the response for events that are handled properly have their timezone info in the timezone field of dtstart, and then a zone object gets created

{ "year": 2024, "month": 10, "day": 29, "hour": 14, "minute": 0, "second": 0, "isDate": false, "timezone": "Romance Standard Time" }

The response of events that are not handled properly have their tzid set to "floating".

{ "year": 2024, "month": 10, "day": 30, "hour": 9, "minute": 0, "second": 0, "isDate": false, "timezone": "floating" }

Honestly I suspect this is a bug in the underlying ical.js package and not in super-productivity's handling of the events.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants