"Add to Calendar" creates entries at the wrong time

[lrasmus]

"Add to Calendar" creates entries at the wrong time

[github-actions]

Welcome to US-RSE! We are excited that this is your first issue!

[danielskatz]

I think you meant to say "but the calendar entry is created for noon Central time."

[lrasmus]

I did, corrected, sorry and thank you @danielskatz!

[lrasmus]

From the non-minimized code posted in PR#1058, if you call the addToCalendar function and specify in the data a timezone, it ultimately uses this function n and adjusts the original date/time that you provided to offset it. For example, I am in Central timezone, if you pass "America/New_York", it will subtract an hour from the date that it gets. I think this is the problem - it explains why when I download a calendar it is an hour off.

        n = function(e, t) {
            if (e) {
                if (t) {
                    var a = new Date(e.toLocaleString("en-US", {
                            timeZone: t
                        })),
                        A = e.getTime() - a.getTime();
                    return new Date(e.getTime() + A)
                }
                return e
            }
        },

I think the solution is to remove line 28 from _includes/buttons/add-to-calendar-button.html https://github.com/USRSE/usrse.github.io/blob/main/_includes/buttons/add-to-calendar-button.html#L28

    // Event timezone. Will convert the given time to that zone
    timezone: "America/New_York", 

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 timezone parameter showed events being created with the correct time with this change applied. Am happy to proceed with PR, but wanted to first ask if anyone with more historical knowledge of the site can say if this will break something that I'm not thinking of?

[exoticDFT]

From the non-minimized code posted in PR#1058, if you call the addToCalendar function and specify in the data a timezone, it ultimately uses this function n and adjusts the original date/time that you provided to offset it. For example, I am in Central timezone, if you pass "America/New_York", it will subtract an hour from the date that it gets. I think this is the problem - it explains why when I download a calendar it is an hour off.

        n = function(e, t) {
            if (e) {
                if (t) {
                    var a = new Date(e.toLocaleString("en-US", {
                            timeZone: t
                        })),
                        A = e.getTime() - a.getTime();
                    return new Date(e.getTime() + A)
                }
                return e
            }
        },

I think the solution is to remove line 28 from _includes/buttons/add-to-calendar-button.html https://github.com/USRSE/usrse.github.io/blob/main/_includes/buttons/add-to-calendar-button.html#L28

    // Event timezone. Will convert the given time to that zone
    timezone: "America/New_York", 

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 timezone parameter showed events being created with the correct time with this change applied. Am happy to proceed with PR, but wanted to first ask if anyone with more historical knowledge of the site can say if this will break something that I'm not thinking of?

@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 _includes/events/event-time.html, specifically line 16 - var tz = Intl.DateTimeFormat().resolvedOptions().timeZone; This file is what sets the time stamp we put before the "Add to Calendar" button.

[exoticDFT]

Actually, if you simply replace line 28 with timezone: Intl.DateTimeFormat().resolvedOptions().timeZone, instead of timezone: "America/New_York", it seems to get the correct timezone and states that in at least Google Calendar.

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.

[lrasmus]

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.

[exoticDFT]

@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 🙂

[danielskatz]

Let's go ahead and do this, then we can also merge #1055 and delete #1058 (unless we resolve this through that)

[lrasmus]

@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.

[danielskatz]

@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...

[lrasmus]

I'm good with whatever is preferred - I can definitely see the logic behind 2 PR and separation