A recurring meeting has two clocks

Imagine a team meeting every Monday at 09:00 in Berlin. A UTC timestamp fixes the first occurrence. RFC 3339 describes timestamps as instants with a stated relationship to UTC. It leaves local scheduling rules outside its scope. That timestamp tells everyone when to join once. The team’s recurring promise is Monday at 09:00 on Berlin’s clock.

The local clock can stay steady

A recurring meeting needs a weekday, a local time and a location-based time zone. IANA’s time zone database describes zones such as Europe/Berlin using rules for local civil time. A calendar can apply the rules for each meeting date to find its UTC instant. When the local offset changes, the meeting can remain at 09:00 in Berlin while its UTC hour changes.

Adding seven days to the first UTC instant keeps the same UTC hour each week. Across a local clock change, the meeting may then appear at a different time in Berlin. Reusing the first invitation’s numeric offset creates a similar problem: that offset describes one date, while zone rules cover changing dates.

Choose which clock stays steady

For a standing local meeting, keep its weekday, local time and zone, then calculate each occurrence. For a single event that must happen at one shared moment, use an instant and display it in each participant’s zone.

IANA warns that governments can change future clock rules. Recheck upcoming invitations when those rules change.