WhenMathDST Season Meeting Planner
A recurring meeting held at a fixed local time in your own zone can appear to move by an hour for a remote participant, simply because one of the two zones changed its clocks and the other did not. This shows exactly which occurrences shift and by how much.
Worked example
A 9 AM New York meeting shown in London starts at 2 PM London time in the winter, when both zones sit five hours apart. Once United States clocks spring forward in March while the United Kingdom has not yet done the same, the gap narrows to four hours and the same 9 AM New York meeting now shows as 1 PM in London, a full hour earlier than before, even though nothing about the meeting itself changed. Once the United Kingdom also springs forward a couple of weeks later, the five-hour gap returns and the London time shifts back to 2 PM, a second shift entirely caused by the second zone catching up rather than the first zone changing again.
Common mistakes
- Assuming only one shift happens per year. Two zones with different daylight saving transition dates can each shift the relationship independently, producing two separate changes a few weeks apart.
- Forgetting that the home zone's own clock time never changes here. Only the remote zone's equivalent local time is recalculated for each occurrence.
Limitations
This checks a weekly recurring meeting only, and it depends on your browser's own current time zone data for both zones' transition dates, which is kept current through ordinary browser and operating system updates.
Frequently asked questions
- What if neither zone observes daylight saving time?
- Then the remote local time never shifts across any of the checked occurrences, since there is no transition to cause one.
- Does this tell me how to reschedule the meeting?
- No, it only shows where a shift happens. Any rescheduling decision is left to you and the other participants.