A spring clock change can make a local time nonexistent

The useful distinctions

• Some timezone transitions skip a range of local clock values.
• A local date and location can therefore describe an invalid wall time.
• Choosing a nearby valid time is not the same as confirming the source’s intent.

Do not manufacture a valid hour

A local clock can move forward across a range of values that do not occur on the transition date. If an announcement falls inside that gap, preserve the stated value and identify the ambiguity. Do not quietly move it to the next available hour or assume the preceding offset applies. Either choice could create a different event instant from the one the organiser intended, while making the record look deceptively complete.

Ask for the intended instant explicitly

A source can resolve the problem by supplying a corrected local time with its location and date, or an equivalent unambiguous timestamp. Keep that correction alongside the original announcement rather than erasing the reason for the change. The viewer’s task is not to guess the organiser’s policy for impossible local times. It is to identify that the stated combination cannot be treated as an ordinary valid slot under the checked timezone rules.

Hypothetical worked example

Under the checked IANA rules, America/New_York moves from 01:30 to 03:30 between the corresponding UTC examples on 14 March 2027. A fictional announcement for local 02:30 on that date therefore needs clarification; it cannot be accepted as a normal occurring wall time. The correct enquiry preserves “14 March, 02:30, New York” and asks for the intended instant rather than silently selecting 01:30 or 03:30.

A focused way to proceed

1. Retain the announced date location and clock exactly.
2. Check the date-aware transition using current timezone data.
3. Ask the organiser for a corrected or unambiguous timestamp.

When to stop or ask for help

Request a corrected date-aware local time or explicit event instant from the announcement’s source.