Just discovered this on Jesse's stream: If a user is located in a timezone outside of America/New_York (the default selection), it appears the toastui calendar is still trying to offset the calendar when I specifically tried to suppress it. What an ordeal!
Diagnostics
I can try using puppeteer to emulate a different timezone from the client side, per instructions on this post. In the R ecosystem, we can try using the {crry} package which wraps the {crri} package for headless browsing that mimics puppeteer.
Possible Solutions
This issue on the tui.calendar repo comes from a similar use case of someone wanting to use the server time zone instead of the client's time zone on initial load, and they want to handle custom time zone selections on their end. The authors reference the Timezone object as a way to dynamically apply the offset.
Just discovered this on Jesse's stream: If a user is located in a timezone outside of America/New_York (the default selection), it appears the toastui calendar is still trying to offset the calendar when I specifically tried to suppress it. What an ordeal!
Diagnostics
I can try using puppeteer to emulate a different timezone from the client side, per instructions on this post. In the R ecosystem, we can try using the
{crry}
package which wraps the{crri}
package for headless browsing that mimics puppeteer.Possible Solutions
This issue on the
tui.calendar
repo comes from a similar use case of someone wanting to use the server time zone instead of the client's time zone on initial load, and they want to handle custom time zone selections on their end. The authors reference the Timezone object as a way to dynamically apply the offset.