Some issues with Google Calendar

[furmandev]

Description

First off, love this project! I've been looking for something exactly like this.

Having some issues when importing to Google Calendar. Here's the unexpected behavior:

• Events don't have details like the leekduck url or image (I see in the .ics file that these details are there)
• Events are in the Universal Time zone and I am unable to change it

I'm not sure if these issues are purely Google's fault and there's no workaround. Just wanted to report my findings

Version

N/A - pulled ics file on Jan. 4 2023

Steps to Reproduce

1. go to google calendar settings
2. click "Add a Calendar" > "From URL" should be this screen
3. input the gocal url: https://github.com/othyn/go-calendar/releases/latest/download/gocal.ics

Screenshots

No response

Device

Macbook Pro, Samsung S22 Ultra

Operating System

mac, android

Additional Context

No response

[othyn]

Thank you! Glad its helped.

Events don't have details like the leekduck url or image (I see in the .ics file that these details are there)

So far, I've not yet used a calendar client that will render the images. Apple Calendar (the one I use) also doesn't, I think it may just be an Outlook thing.

As for the URL, I'm not sure. I don't really use Google Calendar and spending some time searching around the web for issues related to this doesn't yeild anything worth while.

I loaded the calendar into a spare Google account I have and I can see the issue with it not coming through. Given the lack of information online, I played around with it a little and I think its due to Google not having a 'URL' field. I'm only going on the fact that if I create a new event in Google Calendar, there is no specific field to enter a URL into like in Apple Calendar (for example).

As a work around I can simply add the URL to the event description so its located in multiple places for calendar clients that don't support the native URL field.

Events are in the Universal Time zone and I am unable to change it

Ah, this issue again haha. I've spent a long time trying to fix this.

In its current state, there is zero timezone information embedded in the generated ICS file, the TZID for the calendar and all associated timezone information at calendar level is omitted and the same goes for each event. This including the removal of Z as a suffix on event times to ensure the event isn't interpreted as UTC, that took a while to solve and resulted in commit f5b5243, at which point I thought the timezone issue was put to bed.

Given no timezone information, the calendar client is meant to interpret that as local time and act accordingly to place events into the calendar at the time stated in the event regardless of timezone, making all events local time by nature.

I've spend the last few hours debugging this between Apple Calendar and Google Calendar and trying various combinations of setting and omitting the timezone, and nothing seems to work consistently.

Apple Calendar appears to follow what the RFC guidance states, reacting to local time if there is no timezone set, and a timezone if one is set.

Google Calendar appears to follow the RFC when importing a local .ics calendar file, reacting to local time if there is no timezone set, and a timezone if one is set. However, this appears to change when doing it from a 'URL Subscription', as it defaults to importing as a UTC calendar no matter how I try and do it.

Searching around online, I can't really find anything that documents or proposes a work around to solve this behaviour, specifically around local time events in Google Calendar ICS 'URL Subscriptions', as imports appear to work as intended.

Really sorry to say, but I think its a Google thing. All timezone information is stripped from the .ics files to allow for clients to interpret it as local time. Google Calendar seems to just yolo onto UTC no matter what though...

The only real fix for this (as it appears) is to generate timezone specific variants of each calendar alongside a local time one, for clients that struggle with interpreting local time events, which at this time appears to just be Google Calendar over 'URL Subscriptions' only. A really weird behaviour.

Its possible for me to do, but its a lot of calendar variations to generate and nicely present on the website. Will have a think.

[othyn]

GH auto closed as I mentioned it in a commit, but I'll re-open it as I do want to explore timezone specific variants as a possibility.

[furmandev]

Thanks for the response! It does look like a Google thing. I'll still use it and know that community days and such will just have the wrong time on my calendar until Google improves things on their side.

Thanks again for the great project!

[othyn]

🙌 I'm currently working on doing timezone variants of the calendars, will ping you once its released.

[othyn]

So... this is mainly just for future reference on this thread instead of a direct reply.

Looking at https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases, there is no limit on release attachments or bandwidth.

The reason this is an issue is under the current generation, with the combination of all timezones and calendar types, its around ~4,000 calendar files that are generated, all of which are only around 1-20kb.

I'm not sure on whether to release this or not, as its a lot of release assets to publish and I'm not sure if GitHub will even do it. Especially at a daily release frequency.

All the implementation is ready to go and sat in the multi-timezone branch, this is the only hesitation pending release.

I'd love there to be a more generic and smaller timezone set to support, but I'm not having any luck on finding a compomise between a decent coverage vs. published timezones.

---

[selfish]

Hey, loving the service, and I'm just chiming in to say I'd also love to see the timezone fix coming in to play, and drop in my suggestion:

I can think of two approaches for the timezone problem:

Option 1, Easier: Ignore country specific timezones, and just use 24: UTC-12, ...,UTC-1, UTC, UTC+1, ..., UTC+12. This will reduce the calendar account to a couple hundred, instead of around 4k.

Option 2, A bigger solution, but I think this would be the next level service:
Have n endpoint on the site like /cal or something, that reads the current releases and adjusts them with two flags:
events (or filter, or any other name) and tz.
So actually only generate the everything calendar, have the endpoint read and cache that, and on request, filter the events and adjust the timezones.

Example:
https://gocalendar.info/cal -> return the everything calendar with UTC tz.
https://gocalendar.info/cal?tz=Pacific/Tahiti -> return the everything calendar with Pacific/Tahiti tz.
https://gocalendar.info/cal?tz=Pacific/Tahiti&events=community_day,elite_raids,event -> return only events from these categories + adjusted TZ to Pacific/Tahiti

I think it should be fairly straightforward to create a template file for the backend to quickly replace the values when serving the calendar data, and speed is not really a consideration because it's the calendar app that fetches it, not a user sitting and waiting for things to load.

I'm happy to collaborate on creating the second solution if this is something you would consider implementing!

[othyn]

@selfish awesome suggestion, thank you for getting involved with the project! I'm happy to accept PR's on this.

Option 2 is an awesome suggestion and was my original path. In typical systems design it would be the approach to take. One of the projects core requirements though is that its all hosted on GitHub Pages, as I wanted to keep it light weight, easily automated and free to run. As some form of backend will be required to ensure the calendar clients can use the endpoint, this approach cannot easily be taken without also overhauling the infra side too and breaking those requirements. So although its absolutely the right path to take, I'm not sure its perhaps the best one in this scenario.

Option 1 is a really good shout though, I hadn't considered that. When I have time I can look into that avenue and see what the results are, with some form of dropdown on the website that pairs off where you are to what timezone version you need for ease of UI. Or, happy to accept a PR! 😉