Handling time: UTC, ISO 8601 and time zones

Goal

Avoid the classic time bugs: naive timestamps that mean different things on different machines, daylight-saving jumps, and comparisons between values in different zones.

Prerequisites

A datetime library with explicit time-zone support and access to the IANA time zone database (Python's zoneinfo module).

Steps

1. Record instants (when something happened) as UTC and serialise them as RFC 3339 strings with an explicit offset (2026-09-15T12:00:00+00:00 or Z).
2. Reject naive input at the boundary or attach the documented zone explicitly; never assume the server's local zone.
3. Keep time-zone-aware objects internally; comparisons and differences between aware instants are unambiguous.
4. Convert to a named IANA zone (Europe/Zurich, not a fixed offset) only for display or for calendar rules, because offsets change with daylight saving and legislation.
5. Treat "the same time tomorrow" and "the first of next month" as calendar arithmetic in the user's zone, then convert back to UTC for storage.
6. Store the zone identifier alongside future local-time events (appointments), since the offset may change before the event.

Expected result

Timestamps compare correctly across services and machines; displayed times are right in the user's zone; scheduled events survive daylight-saving changes.

Limits and test basis

Leap seconds are outside most libraries' models. Historical zone data changes with database updates; keep it current. The rules follow the cited references.