Recognize the repeated-time state
A backward clock change can make a local interval occur twice. When your selected date and time has two matches, the app shows the candidate offsets and asks for the earlier or later instance. Both candidates are valid; the planner cannot infer which one an organizer intended.
Check the New York example
On 1 November 2026, 01:30 in America/New_York has two candidates. The earlier instance uses UTC−04:00 and equals 05:30 UTC. The later instance uses UTC−05:00 and equals 06:30 UTC. They are one hour apart despite having the same local date and clock label.
| Choice | New York | UTC |
|---|---|---|
| Earlier | 01:30 · UTC−04:00 | 05:30 |
| Later | 01:30 · UTC−05:00 | 06:30 |
Select the intended instance
- Compare the date, city identifier, and offset with the organizer’s instruction.
- Choose Earlier instance or Later instance.
- Review the resulting local date and time in every other city.
- Check the end time and working-hour status before exporting.
Review recurring occurrences
A weekly preview can contain ordinary weeks and one repeated-time week. Use the recurring policy or the occurrence’s explicit choice, then inspect the affected row. Changing the choice moves that event’s instant; it does not merely change an abbreviation. Any unresolved occurrence prevents export of the series.
Verify the calendar result
The ICS event stores the selected resolved UTC start and end. After import, compare its instant and the calendar’s display zone. A screenshot of an offset-free 01:30 is not enough to verify which instance was chosen. Keep the project backup if you need to revisit the decision.
Sources
Follow the original references for the rules and formats used in this guide.