-
Notifications
You must be signed in to change notification settings - Fork 85
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
"Add to Calendar" creates entries at the wrong time #1068
Comments
Welcome to US-RSE! We are excited that this is your first issue! |
I think you meant to say "but the calendar entry is created for noon Central time." |
I did, corrected, sorry and thank you @danielskatz! |
From the non-minimized code posted in PR#1058, if you call the
I think the solution is to remove line 28 from
I can see why this parameter was included, the documentation for this plugin we're using (I think this is the right one): https://www.addevent.com/documentation/add-to-calendar-button recommends providing it. However, we provide our dates/times in UTC, so I don't think any adjustment is needed. Local testing after removing that |
@lrasmus Great catch! I tested this change locally and everything seems to work on my local setup. This should not affect anything other than the button this file creates. So, should be safe to modify. My only potential concern is if someone has their calendar app setup to use a different timezone by default than what the browser thinks, we may still run into some conflicts. It may be worth trying to set this timezone variable with the same timezone that is used for the timezone string that appears in events. In other words, maybe using something similar to code in |
Actually, if you simply replace line 28 with By removing the timezone line entirely, I was not seeing a timezone stated in Google Calendar, which I think would result in it defaulting to whatever the individual's Google Calendar is set too. And 99% of the time, I'm sure that would be the timezone the browser would also think. But seems worth enforcing it to match what the event's page states above the button. |
Thank you @exoticDFT, it's a great suggestion and it seems to work in my local testing too. Do you want to make the change/PR with suggested fix? I feel like you're the one who really "solved" this, and I would hate to take credit unfairly. |
@lrasmus feel free to make the PR with that change, if you would like. I would have never looked into it without you recognizing the problem in the first place. I'd say this is definitely yours to claim 🙂 |
…y creation Actual fix suggested by @exoticDFT. Previously "America/New_York" was passed as the time zone to create calendar entries from the "Add to Calendar" button, however this was generating the calendar entry then with the wrong local time (e.g., it was set an hour off in a non-Eastern time zone). Instead, pass the user's timezone.
The "Add to Calendar" button (per issue USRSE#1068) was creating entries anchored in "America/New_York" which meant it was shifting the time to the other time zone for non-Eastern TZ folks. This uses the current time zone for the user. Credit to @exoticDFT for the actual code fix to use
@danielskatz - this incorporates the fix from @exoticDFT for the calendar issue. I agree to delete #1058 and if we're good with everything here we can get #1055 merged. |
@lrasmus - It feels a bit wrong to me to have these fairly different changes in the same PR in terms of someone wanting to look at the calendar code in the future. I was expecting a new PR for that, that we would merge, then we would create the new events by merging #1055. What do you think? I could be convinced this way is ok too... |
I'm good with whatever is preferred - I can definitely see the logic behind 2 PR and separation |
…dar entries" This reverts commit 9682336.
The "Add to Calendar" button (per issue USRSE#1068) was creating entries anchored in "America/New_York" which meant it was shifting the time to the other time zone for non-Eastern time zone folks. This uses the current time zone for the user. Credit to @exoticDFT for the actual code fix to use
…1085) The "Add to Calendar" button (per issue #1068) was creating entries anchored in "America/New_York" which meant it was shifting the time to the other time zone for non-Eastern time zone folks. This uses the current time zone for the user. Credit to @exoticDFT for the actual code fix to use
This surfaced as part of PR#1555, but appears to be more widespread. The "Add to Calendar" button creates entries, but they appear on my calendar at the wrong time. Here's an example for a meeting on 2023-02-10. It shows up correctly in the site as occurring at 1pm Central time, but the calendar entry is created for 12pm Central time.
The text was updated successfully, but these errors were encountered: