Availability slots across timezones and DST

Availability slots across timezones and daylight saving time (DST) can be tricky to implement correctly. The problem arises when a wall-clock time is treated as a fixed point in time, rather than a location-specific instant.

To resolve this issue, an availability engine should build each boundary as a wall-clock instant in the business's timezone, resolve the offset there, and only then convert to UTC. This ensures that the same time slot maps to the correct instant, regardless of the date or timezone.

For example, 09:00 in Paris during summer (UTC+2) maps to 07:00 UTC, while in winter (UTC+1) it maps to 08:00 UTC. The same 09:00 string represents two different instants depending on the date. Therefore, the rule to ensure correctness is to build the window in the business's timezone, resolve the offset there, and only then convert to UTC.

The common mistake is to compute slots in UTC (or the server's clock) instead. This leads to an hour being off across timezones, and phantom slots appearing during DST changes. Building the slots in the business's timezone prevents these issues, as the date library will automatically resolve the offset for that specific date and location.

When performing overlap checks between time intervals, store the slots as UTC instants and compare them using a half-open interval overlap on milliseconds. This ensures the comparison is location-independent and eliminates any timezone-related errors.

Following this rule will prevent the headache of availability engines working fine during regular weeks but growing phantom slots on DST change Sundays. The key takeaway is that a 09:00 time is wall-clock time in the business's timezone, not a fixed instant, and should be handled appropriately to avoid time-related bugs.