I arrived 1 hour late for a zoom meeting a few weeks ago. At meeting at which I was presenting. I checked and double checked the calendar event to make sure I arrived at the right time. Daylight savings time hadn't changed for me recently, and nor had it changed for the organizers (who advertised the event in GMT).
The problem was that the calendar advertising the recurring event was set to PST. And daylight savings had changed in California (PST -> PDT or the other way around). The result was that the calendar event shifted by 1 hour local time for me and every other attendee who subscribed to the calendar event.
This situation sucks, and its really confusing to everyone. But I can't think of a way around this whole issue:
- If recurring calendar events weren't set to a timezone (and thus, just worked off GMT), then all recurring calendar events would drift forwards or backwards when daylight savings changes happen
- If recurring calendar events are set to some local time zone, then things like this happen - which really confuses everyone involved.
I mean, sure - in an ideal world we'd get rid of time zones. But until then, it seems like we're stuck with this problem.
(Though at least daylight savings time is slowly being phased out in some countries.)
A great illustration of why we should shun them whenever we can.
Calendar apps are exactly where the full and monstrous complexity of time zones emerges, and I don't envy anyone who works on one.
My case is that the problem doesn't have to happen in the other direction and this unforced error is made frequently. There are a huge class of recurring events where drifting by an hour on the local clock won't make a difference, but either skipping something or doing it twice is bad.
What you're describing strikes me as a bug in the absolute sense: nothing should be displaying PST during a time frame when that time zone isn't in use.
Again, don't sign up to have these problems if you can possibly avoid it.
The solution is to make the calendar aware of all the time zones relevant to an event (e.g. the organizer’s time and the presenter’s time), so it is able to display all the times and warn when timezone changes might be relevant. (Each attendee may have a different time too, but those times do not need to be recorded in the event but can be handled locally on each attendee’s devices.)
There is the extra problem that the standard explanatory names for timezones that appear in the CLDR are very confusing, eg British time is referred to as GMT even though that is wrong for more than half the year in the summer.
The problem was that the calendar advertising the recurring event was set to PST. And daylight savings had changed in California (PST -> PDT or the other way around). The result was that the calendar event shifted by 1 hour local time for me and every other attendee who subscribed to the calendar event.
This situation sucks, and its really confusing to everyone. But I can't think of a way around this whole issue:
- If recurring calendar events weren't set to a timezone (and thus, just worked off GMT), then all recurring calendar events would drift forwards or backwards when daylight savings changes happen
- If recurring calendar events are set to some local time zone, then things like this happen - which really confuses everyone involved.
I mean, sure - in an ideal world we'd get rid of time zones. But until then, it seems like we're stuck with this problem.
(Though at least daylight savings time is slowly being phased out in some countries.)