Every March and November (in the US - different dates elsewhere), clocks shift by an hour. And every time, meetings that were scheduled weeks in advance suddenly happen at the wrong time for some participants. Here's why, and how to avoid it.
New York is UTC-5 in winter and UTC-4 in summer. London is UTC+0 in winter and UTC+1 in summer. And critically, they don't switch on the same date. For about three weeks each spring, the US has already "sprung forward" but the UK hasn't yet.
If you scheduled a meeting as "3pm ET / 8pm GMT" during winter, that same UTC time becomes "3pm ET / 7pm BST" after the US changes but before the UK does. Or if you think of it as "always 8pm London time," it's suddenly 4pm ET instead of 3pm.
Most calendar apps handle recurring events reasonably well within a single timezone. The problem shows up when:
This is the part most people miss. DST transitions aren't synchronized globally:
A team spanning New York, London, and Sydney has to navigate at least four transition dates per year where the relative time difference changes.
The fix is straightforward: always use IANA timezone names, not UTC offsets. "America/New_York" automatically accounts for whether it's EST or EDT. "UTC-5" does not.
When scheduling across time zones, use a tool that stores each person's IANA timezone and computes overlaps at the moment of display - not at the moment of creation. willFlock does exactly this: times are stored in UTC and converted to each attendee's local timezone using the Intl API, which pulls from the up-to-date IANA timezone database.
If any of those raise a flag, double-check the time with your attendees before the day arrives.
Need to schedule across time zones? willFlock handles DST automatically - create a free event and let everyone mark availability in their own timezone.