Closed gkovats closed 3 months ago
Name | Link |
---|---|
Latest commit | 6d12ef7c82157a1a10ed6c03e18ba120e53e7acc |
Latest deploy log | https://app.netlify.com/sites/tsml-ui/deploys/66b93a9eb319a50008e95002 |
Deploy Preview | https://deploy-preview-403--tsml-ui.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
thanks @gkovats !! seeking to understand this issue a little better. do you get the wrong tz when you add this meeting ics? https://aasanjose.org/meetings?search=one+big+tent&meeting=one-big-tent
im on eastern right now and see 9pm, which is correct. wondering why it would work here and not on the dharma meeting.
ill research more when i get in front of a computer
i see what the issue is. this only affects sites with a timezone-agnostic meeting finder
https://github.com/code4recovery/tsml-ui/blob/main/src/helpers/load-meeting-data.ts#L256-L260
if there is no global timezone set, it sets start and end to your local timezone. would not affect san jose because it's America/Los_Angeles
This is for issue #402
Problem I believe is the DTSTART format in the ICS file is getting Timezone, but then getting a date stamp relative to the current user's timezone, which gets mixed up:
First part is the timezone prefix, so the calendar app knows the context, and the second part is the timestamp formatted, which is picking up the user's local browser relative time. The two don't mix. So, just enforced that when we pass a timestamp here, the time is relative to that given timezone. Tested against the issue's Dharma meetings, they're importing correctly.