Meeting windows on daylight-saving days
HourAlign does not split the baseline day into a fixed 24-hour grid. It walks every real instant of the first city’s local date, so spring-forward and fall-back days stay honest.
What the planner actually uses
The meeting date is the local calendar date of the first city in the list. That city is the baseline.
Every other person is checked against that same stretch of real time, using their own local date and clock. A 30-minute meeting is 30 real minutes, not 30 civil clock ticks that might skip or repeat.
Why a 24-hour grid is the wrong model
On a spring-forward day the baseline local date can last 23 hours. On a fall-back day it can last 25. Some zones, such as Australia/Lord_Howe, move by 30 minutes.
HourAlign asks the browser’s IANA data which local times exist that day. Times that never happen are skipped; times that happen twice are two different instants.
How to plan around a change
1. Put the city whose calendar date you care about first.
2. Enter that local date — the day of the change, or the day before or after if you are comparing.
3. Keep each person’s work hours as their usual local start and end on that civil date (for example 09:00–17:00).
4. Read the result’s local dates. They can differ from the baseline date, and they can show a next-day or previous-day label.
Example
Take America/New_York on 2026-03-08, when 02:00 jumps to 03:00. A New York work window of 09:00–17:00 is still “nine to five on that date”; the missing hour is earlier in the morning and is simply not a real instant.
Add London 09:00–17:00 and Berlin 09:00–17:00 the same way. The overlap is computed in UTC instants, then shown again in each local clock.
Overnight shifts
This version requires each person’s start to be earlier than their end on the same local day. Overnight windows such as 22:00–06:00 are not modelled yet.