Failure one: the event moves

An event stored as an absolute instant — a UTC timestamp — is fixed in physical time, not on the wall clock. Store “Tuesday 19:00” in summer as a UTC instant and it will render as 18:00 or 20:00 after the clocks change, because the instant did not move but the clock did.

This is why a weekly class can be correct for months and then be an hour out from one week to the next. The fix is structural: store the wall-clock time and the zone's name, and derive the instant when you need it. Then 19:00 is 19:00 in October and in June.

Failure two: the length is wrong

This is the subtle one, and the tool above shows it. Take a two-hour event starting at 01:30 on the morning the clocks go back. Stored as a duration — two hours — it ends at 02:30 on the wall clock, having run for a genuine two hours through the repeated hour. Stored as an end time of 03:30, it runs for three hours in reality.

One of those is right and the other is not, and which one you get is determined by a storage decision made long before anyone thought about October. Most calendar formats and most plugins use an end time, which is why this is a real and recurring problem.

Failure three: the time does not exist

On the spring morning, clocks jump straight from 02:00 to 03:00 across much of Europe. There is no 02:30 that day. An event stored at that wall-clock time is not merely wrong — it does not describe a real moment, and every piece of software resolves it differently. Some shift it forward, some back, some drop the occurrence.

The autumn version is the mirror image: 02:30 happens twice, and which one is meant is undefined. The tool above flags both cases rather than picking one quietly. If your recurring event's time falls in that window, move it — it is the only real fix.

Why it is not just twice a year

Northern and southern hemispheres change on different dates, and different countries change on different days even within Europe and North America. So the gap between two cities is not constant: for a couple of weeks each spring and autumn, London and New York are four hours apart instead of five.

If you run events across countries — a touring show, an online course with international attendees — those fortnights are when your published times are wrong. The tool above will show you exactly when each zone changes.

The rules that avoid all three

Store the wall-clock time. Store the zone's name, not its offset. Store a duration, not an end time. Derive UTC when you need to sort or compare, and derive it again if the timezone database changes. Every failure on this page disappears.