Convert timestamps without losing the time zone

Compare two ways to describe one instant

2026-01-15T09:00:00+08:00 and 2026-01-15T01:00:00Z describe the same instant. Enter each into the timestamp converter and compare the Unix result. If a database round trip changes the instant, inspect whether the offset was dropped when parsing or serializing.

In America/Los_Angeles, 2026-03-08 02:30 falls in the spring gap. On 2026-11-01, 01:30 occurs twice: 01:30-07:00 corresponds to 08:30Z and 01:30-08:00 to 09:30Z. Keep both cases in tests; silently selecting one can move an appointment by an hour.

For a recurring local appointment such as 09:00 every weekday, also preserve the named zone and the recurrence rule. A fixed UTC offset describes one instant but does not carry future daylight-saving rules. Recompute occurrences using current time-zone data.

Name the source zone

When input is a local wall-clock value, keep its IANA time-zone name beside it. A bare value such as 2026-03-08 02:30 cannot be converted reliably because the sender's location is missing.

Test daylight-saving boundaries

Some local times never occur when clocks jump forward; others occur twice when clocks move back. Reject or request clarification for ambiguous input instead of silently choosing an offset.

Store instants, format at the edge

For events, store an unambiguous instant such as Unix time or an offset-aware ISO value. Format it for the user's selected locale and time zone only when presenting it.