Spotlight hour calendar not using correct local time #6
Comments
|
Having similar issues. What I found is just importing the ICS file directly into another calender works fine, but subscribing sets the times out of whack. I am GMT + 1 (BST) Spotlight Hours are an hour ahead |
|
I like subscribing so it will update for me automatically. I imagine an
import means you have to update it yourself by reimporting periodically?
…On Fri, Aug 11, 2023 at 2:50 PM PokeIMGs ***@***.***> wrote:
Having similar issues.
What I found is just importing the ICS file directly into another calender
works fine, but subscribing sets the times out of whack.
I am GMT + 1 (BST)
Spotlight Hours are an hour ahead
Raid Hours are 7 hours ahead
Go fest global is an hour ahead
Community day is 5 hours ahead
City Sefari Seoul and Barcelona are an hour ahead, but Mexico is the right
time (funilly enough this is after daylight savings ends)
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD5XIBJEKBCA7OBBW5U57WLXUZ5HHANCNFSM6AAAAAA3KGCMIY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Yup, I would also prefer to use the subscription for those reasons but am
at a loss as to why the times are so different
…On Fri, 11 Aug 2023, 21:50 Shahrum Amiri, ***@***.***> wrote:
I like subscribing so it will update for me automatically. I imagine an
import means you have to update it yourself by reimporting periodically?
On Fri, Aug 11, 2023 at 2:50 PM PokeIMGs ***@***.***> wrote:
> Having similar issues.
>
> What I found is just importing the ICS file directly into another
calender
> works fine, but subscribing sets the times out of whack.
>
> I am GMT + 1 (BST)
>
> Spotlight Hours are an hour ahead
> Raid Hours are 7 hours ahead
> Go fest global is an hour ahead
> Community day is 5 hours ahead
> City Sefari Seoul and Barcelona are an hour ahead, but Mexico is the
right
> time (funilly enough this is after daylight savings ends)
>
> —
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AD5XIBJEKBCA7OBBW5U57WLXUZ5HHANCNFSM6AAAAAA3KGCMIY>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BA7KLHWGBZSO54VFZS573OTXU2LJLANCNFSM6AAAAAA3KGCMIY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I'm having a similar issue. I'm on GMT-5, and the following are at different times for me: Events calendar synced fine I think, though Noxious Swamp should end on Tuesday and not Monday |
|
This is the same issue as #4, it appears to be a long standing issue specifically with Google Calendar's processing of the feed. For whatever reason, it seems to imply a TZ from some arbitrary place and use that for the subscribed feed. All other calendar services/clients do what they are supposed to and just use the local users TZ. I have no idea why it does it and all the fixes I've put in appear to have made no difference. I purposefully do not embed a TZ within the generated files so that the consuming client will use its own and correctly translate it into the local TZ. #5 aimed to resolve this issue, but I haven't had time yet to look into it properly as its a large amount of infra work, basically to generate versions for all timezones on the fly, which appears to be the only way to have it work with Google Calendar. Which is what I wanted to avoid at all costs as it adds a ton of complexity. A dynamic URL that holds all the necessary query parameters (what calendars, TZ's, etc.), so you can still subscribe to it, but each time its visited a service worker can spit out the ICS file dynamically. If someone knows a concrete fix for this, or how the files can be correctly imported to Google Calendar using the users local TZ, I'd love to hear it as at this point I'm stumped. |
|
Hi Ben, Thanks for the reply!
Is there a recommended service or calendar app that you know of that
doesn’t run into the issues Google Calendar does? I’m an Apple user so I
suppose I could add the calendar feeds directly to the iOS and Mac default
Calendar apps. Just wanted to see if you had any other service/app
suggestions that work well for you. Thank you!
…On Thu, Aug 24, 2023 at 5:01 AM Ben ***@***.***> wrote:
This is the same issue as #4
<#4>, it appears to be a long
standing issue specifically with Google Calendar's processing of the feed.
I have no idea why it does it and all the fixes I've put in appear to have
made no difference. I purposefully do not embed a TZ within the generated
files so that the consuming client will use its own and correctly translate
it into the local TZ.
#5 <#5> aimed to resolve this
issue, but I haven't had time yet to look into it properly as its a large
amount of infra work, basically to generate versions for all timezones on
the fly, which appears to be the only way to have it work with Google
Calendar. Which is what I wanted to avoid at all costs as it adds a ton of
complexity.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD5XIBLU6ELB2AFEY6NLTOTXW4J5RANCNFSM6AAAAAA3KGCMIY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
No specific recommendations, I just use the default Apple ones too. Google Calendar appears to be the only calendar affected, based on user reports of this issue. |
|
Hello. Poking in to say that the issue still seems to exist. Also using Google Calendar, the times for Spotlight hours show up at 8PM-9PM for me |
|
Not really sure what else I can do on my side, I'd love someone's input with more knowledge or experience with Google Calendar event generation from a dev perspective. Someone submitted an amazing PR for dynamic generation of calendars for each timezone, however its a bit of a heavy handed solution and it feels like there should be an easier solve that I'm just not seeing. It appears to only be a Google Calendar issue with a really weird and non-industry standard interpretation (from what I can see, would like to be corrected on that!) of the generated events. What is extra weird is that it only appears to be a problem for subscriptions, if you manually import the calendar as a one-off into Google Calendar then its fine and imports it with the local timezone interpreted as intended. All events are generated in a way in which forces there to be no timezone and its left to the local client to interpret the timezone. When subscribing to it, Google just forces the timezone to be |
|
On a hunch, I've tried something and it appears to have worked in my testing. I've subscribed to the production one and this new one side by side, and the new one imports into the correct timezone (client) whereas the old one appears an hour after it should. Can people subscribe to the temporary calendar I've created with a potential fix in here and report back? https://raw.githubusercontent.com/othyn/go-calendar/gcal-sub-fix/dist/gocal.ics Please let me know if that subscribes correctly? If it does, I'll have to publish a set of 'If you're using gcal, use this link instead' files specifically for Google Calendar subscriptions. |
Didn't expect such a quick response! I subscribed to the link, though sadly it still seems slightly off (differently so than before, though). That said, I am in Central European Summer Time (CEST) as of right now, and the times WOULD be correct for CET (Winter time). Perhaps Summer/Winter timezones are messing this up? |
|
Yes! I can confirm this new calendar, when subscribed to is showing the
correct times!
Tested using Google cal URL subscription on British Timezone (BST/GMT+1)
…On Mon, 9 Oct 2023, 10:31 gaylie, ***@***.***> wrote:
On a hunch, I've tried something and it appears to have worked in my
testing. I've subscribed to the production one and this new one side by
side, and the new one imports into the correct timezone (client) whereas
the old one appears an hour after it should.
Can people subscribe to the temporary calendar I've created with a
potential fix in here and report back?
https://raw.githubusercontent.com/othyn/go-calendar/gcal-sub-fix/dist/gocal.ics
Please let me know if that subscribes correctly?
If it does, I'll have to publish a set of 'If you're using gcal, use this
link instead' files specifically for Google Calendar subscriptions.
Didn't expect such a quick response!
I subscribed to the link, though sadly it still seems slightly off
(differently so than before, though).
For some examples: Spotlight Hours show up at 7PM-8PM for me, Pokestop
Showcases from 11AM-9PM, Raid Hours from 7PM-8PM... Generally they seem an
hour off for me.
That said, I am in Central European Summer Time (CEST) as of right now,
and the times WOULD be correct for CET (Winter time). Perhaps Summer/Winter
timezones are messing this up?
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BA7KLHTS7DS2SRO7QVSKJZ3X6O77XAVCNFSM6AAAAAA3KGCMI2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJSGY2DKMBWHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
That's like a timezone in a timezone problem haha although I'm currently in BST (UTC+1) and it is working, which is the equivalent summer offset. I need some people in more timezones to test it. I want to make sure its a local timezone fix and not something else, such as just a +1 offset that Google Calendar is applying internally (as CEST being UTC+2 is still leaving only an hour offset).
Awesome, that aligns with my testing too in BST. |
this new calendar still shows the spotlight hours at 1pm on Google Calendar :( |
|
Damn, okay. Thank you for trying it and reporting back, that was a valuable insight into if this was a valid fix or not. I don't think there is much more I can do then, it appears to be an issue specifically with Google Calendar subscription feeds and whatever they are doing to force/ignore timezones from what I can gather. All other clients respect the standards and use the clients local timezone when one isn't specified, appears Google Calendar is the only one to not adhere to that rule, and also only on subscriptions - manual imports on Google Calendar work fine. If anyone has any other ideas or fixes, I'm all ears. The complete re-write approach (PR) is awesome, but I'd rather not go that route if at all possible just due to whats involved. Especially as I don't play the game anymore either. |
|
For what it's worth, Google Calendar used my default time zone (where I live) but it was incorrect for where I currently am, living abroad. |
|
To add to this, this is what is shown in Outlook. My phone however shows it has my timezone, but still 6-9AM.
|
|
This issue is the worst, and a prime example of XKCD 927:
Every. Single. Client. appears to handle the 'standard' timezone signature differently. Some of them interpret the lack of a timezone correctly as 'use the local users timezone'. Some of them read it in as fixed UTC. Some of them read it in as an undefined timezone. Some of them read it in as whatever they feel like that day. It varies per device, per client and per calendar permutation. A thorn in my side on what should have been a very simple 'please just use the users local timezone' implementation. I may run this problem through ChatGPT - as that wasn't an option when this was created, as I've exhausted just about every single blog, docs and SO post imaginable on this problem to try and resolve it. Give the AI a run at it lmao |
|
I forked it and ran some versions through chatgpt but didn't have any improvement. |
|
Yeah I had a rather lengthy back and forth with ChatGPT over this, feeding it different examples and trying to get it to generate its own approach and compare. It just confirms the information that I've already found at length on the topic - this shouldn't be an issue and I still cannot understand why it is. The examples that it generates are identical to the ones that this repo does. The goal: Given a hypothetical event, let's say starts at 6:00 PM, users in London and New York will see the event at their respective local times. If a user in London downloads the calendar, they will see the event at 6:00 PM local time in London. If a user in New York downloads the calendar, they will see the event at 6:00 PM local time in New York. The recommended fix, as is already implemented, is to not define a timezone (e.g. That is how the current live implementation of any calendar generated by this tool is generated, so I'm still at at a loss to why any of this is an issue. Google Calendar, Outlook/O365, iOS/iPadOS/macOS (Apple Calendar), etc. all support 'floating time' as defined by the absence of a timezone (e.g. If someone can find a working example on the web for this sort of problem, then I can reverse engineer a solution. I did think I found one in the Formula 1 calendar project, but those events are fixed in time to each timezone, as an F1 race occurs at a fixed point in time within a specified timezone and therefor will need to be timezone adjusted depending on the embedded timezone of which the race takes place in (and therefor translated by the client). Pokemon GO events however occur at the local time for each user, so its not a comparison that can be made. Using a tool like https://icalendar.org/validator.html shows that the file is indeed valid with no errors. There is a warning about headers, but I can't change those as I'm just hosting via GitHub and have no control over the web server. Although that shouldn't have any affect as its just the content type header. If all calendar clients adopted or adhered to RFC 5545 (as they probably should be), then we shouldn't have an issue:
Which in practice translates to:
And thus we find ourselves back at square one. This problem simply shouldn't exist, if everyone is playing by the standards - but as with the modern web, that is rarely the case 🤷 |
|
I've just done another test. No matter what, Google Calendar will always set the timezone of the calendar subscription to 
The events correctly display, and even when changing local timezone, the events remain at the same time respective to the local current timezone and not translated from UTC (they remain at the same time regardless of timezone). Whereas in Google Calendar, the timezone is set to UTC by Google and you cannot change it, going against RFC 5545: 
Meaning if your timezone deviates from UTC, then Google will try to be 'helpful' and translate it into your local timezone, going against RFC 5545's defined handling of floating time. The only solution to this would be something as built in #4 and #5, which is a complete re-write of the project to dynamically generate ICS files in each and every timezone. Urgh. |
|
There's a few comments on Hacker News that point to this being the case since at least 2019:
https://news.ycombinator.com/item?id=19501955
https://news.ycombinator.com/item?id=19501832 I can attest to that last point. There are so many features that iOS Calendar can do that macOS Calendar cannot. Such as changing the starting location when adjusting the travel time... always have to swap to my iPhone to update calendar entries because the macOS version doesn't have feature parity. |
|
There are also many support threads such as this one on the Google support forums in which have been asking for this 'feature' for years. |
|
I assume this is not up to date with your most recent commits, but just wanted to show that my S23 Samsung calendar shows/previously showed my timezone and the GMT time window. |
Instead of generating multiple ICS files, the ICS file should be able to have time per each timezone within the ICS. Something like, -10 (Hawaii) then -8 to -5(Most of North/South America and then -1 to +2(EU and whatnot) then some japan, India, Australia and Newzealand? I recall reading an article about how timezones (without all of this calendar stuff) is crazy complicated to have every timezone perfect. |
|
This is supposed to auto-update right? I manually deleted and added it, and it shows the correct time and the abbreviated title!!! Something I should of also mentioned./reminded... I think CD day was the only one broken. I forgot to point to that being a localized issue and not an overall ICS issue... ooops. |
I didn't realise this! That could be a nice interim fix, I may have a play with doing that. Seems like covering the 9 below may gather the most coverage?
Haha no worries. Odd that it would only happen in the Community Day ICS file... such a bizarre problem all round... |
This is purely based on whatever chatgpt mentioned a couple times. Didn't validate and would take with a grain of salt. (the multi timezone data per ICS file) Happy to see it working though. Thanks a lot for all your work :) |
Ahhhh okay. Yeah having a look at the RFC and some SO posts on this, it doesn't appear to be actually possible in practice, its one |
|
Has this ever been resolved? Ive tried to use it today via Google Calendar, and manually importing the iCal into a Discord bot. The time is always +1 extra. Raids are always 18:00 local time, but in Google its still saying 19:00, in the Discord Bot to organise events, also says 19:00 |
Unfortunately not... I've tried just about everything at this point and nothing will get Google calendar (and now apparently Discord too) to interpret the ICS file properly, specifically when subscribed to. And at this point, I'm convinced it's a GCal bug. The ICS spec says if you don't define a time zone, it should be interpreted in the users local calendar time. Apple (iOS, macOS, etc.) Calendar does this correctly, along with Microsoft too (Outlook, etc.) They both correctly adhere to the spec, even for subscribed calendars. However, Google doesn't. They do if you import the calendar statically/manually from a download of the ICS file, but if you subscribe to it, for some reason it behaves differently. It assumes a time zone and removes the option to specify a time zone override, like you can when manually imported. But ironically, you then dont need the override, as it's interpreted correctly. The only option is a complete rewrite of the entire repo to fix GCal, something similar to the serverless PR, to allow you to select a time zone and what event types you want and store that as a sequence of query parameters for the calendar URL. Basically move from static generation and relying on the client behaviour to offload compute locally, to dynamic generation for each client specific calendar server side, with aggressive daily caching. This way instead of publishing static calendars with no TZ definition, which should work according to the spec, they'd always be rendered server side/dynamically for the TZ you select. My only concern on going that route and utilising something like CF's free tier for it, is that the repo gets a huge amount of hits, in the hundreds of thousands to millions a month, as the calendar clients are instructed to check daily for updates, as aligns with the cadence of updates from LeekDuck. It's an unavoidable requirement. And as we've seen more recently with CF on hacker news, I'm not sure they'd want it on the free tier for long. At the moment, it's all statically generated so that I can utilise GH pages/releases to host the static assets for free. I'm not even sure a cheap £5/mo DO droplet would do it, although I don't mind taking on that sort of cost or equivalent. I just love the simplicity of the deployment/hosting pipeline at the moment haha |
Description
Hello,
I’m currently subscribed to the .ics feed (via Google Calendar) for the spotlight hour calendar and the events are coming through at 2PM EDT instead of 6PM EDT, the expected time for my timezone. Is there a configuration I’m missing?
Version
Latest
Steps to Reproduce
Add calendar feed to Google Calendar
Events loaded
Look at calendar and see events at wrong local time (expected 6pm EDT, seen at 2pm EDT)
Screenshots
No response
Device
All
Operating System
Latest
Additional Context
No response
The text was updated successfully, but these errors were encountered: