Local times may appear incorrectly in automated meeting issue

[dpopp07]

Summary

Depending on the date (I believe due to DST weirdness), the reported meeting time within TC or Working Session meetings may be incorrect for some locales.

For example, the 12-18-24 Working Session meeting (#313) reported the US CST (my time zone) value as America/Chicago | Wed 18-Dec-2024 14:00 (02:00 PM) when it should have been 3pm (when we actually met).

This behavior has been mentioned in comments before (e.g. in the recently opened PR to update the times, #215 (comment), #43 (comment)) but I thought I'd capture it in an issue, alongside a description of what the issue seems to be. I'm not sure it's actually solvable (at least, in a complete way 🙂) but I'd like to try and investigate more in the near future. That said I'm not sure I'll have the time so hopefully this issue at least helps folks to understand the behavior more.

Root Cause

The underlying issue is that a static UTC time will translate to different local times depending on the day of the year, most likely because of DST shifting things around differently in different places.

The starting point for the UTC time comes from this line:

discussions/.github/workflows/meetings.yml

Line 23 in 2ee2a5a

schedules: '2024-03-18T20:00:00.0Z/P2W'

The meet tool used to automate the meeting creation seems to maintain the use of that UTC time (T20:00:00.000Z), while changing the date to reflect the day the meeting is to happen. However, that UTC time will translate differently depending on the day. For example, see these results computed from https://www.timestamp-converter.com/:

Original date

Format	Time
ISO 8601	2024-03-27T20:00:00.000Z
Date Time	(UTC) Mar 27, 2024, 8:00:00 PM
Date Time	(your time zone) Mar 27, 2024, 3:00:00 PM

Latest date

Format	Time
ISO 8601	2024-12-18T20:00:00.000Z
Date Time	(UTC) Dec 18, 2024, 8:00:00 PM
Date Time	(your time zone) Dec 18, 2024, 2:00:00 PM

The tool may need to be updated to better account for this, if the desire is have the meeting continue to be at a static time for certain locales (like 3pm) throughout the year. Of course, it's not really possible to have the static time be consistent across all global locales, which makes the acceptance criteria for this issue tricky, but if there is a time zone (or time zones) to optimize around, the current behavior could likely be improved.