ShipZume
Guide

Storing and transmitting time without creating bugs

Almost every time-related bug in software comes from one of three mistakes: storing local time, storing an offset instead of a zone, or converting more than once. The rules that avoid all three fit on a postcard, and they have not changed in twenty years.

Open a converterSkip to questions

Store UTC, transmit ISO 8601, display local

Store the absolute instant in UTC. A UTC timestamp is unambiguous, sorts correctly, and survives the user changing their zone or a government changing its rules. Storing local time throws away the information needed to reconstruct the instant.

Transmit in ISO 8601 with an explicit offset: 2026-08-14T09:30:00Z, or 2026-08-14T15:00:00+05:30. Both are unambiguous and every language parses them. Avoid Unix timestamps in APIs meant for humans to debug, and avoid locale-formatted strings entirely.

Display in the user's zone, converted once, at the edge. Converting in the middle of a pipeline is how double conversions happen, and a double conversion is invisible until someone in a different zone notices their data is offset by a fixed amount.

The important exception is future events. For a meeting scheduled a year out, storing UTC is wrong: if the government changes its daylight saving rules in the meantime, the meeting moves. Future events should store the local time plus the IANA zone identifier — Europe/London, not +01:00 — and resolve to an instant at display time. That is why calendar formats store a zone reference rather than a fixed offset.

Key facts

Store UTC for past events

Unambiguous, sortable, and immune to rule changes.

Store zone + local time for future events

A rule change would otherwise move the meeting.

An offset is not a zone

+01:00 tells you nothing about what happens in six months.

ISO 8601 everywhere

2026-08-14T09:30:00Z parses identically in every language.

Convert once, at the edge

Middle-of-pipeline conversion is how double offsets happen.

Test around transitions

Most timezone bugs surface only on the two changeover weekends.

How to get it right

1

Set the database to UTC

Both the server and the connection.

2

Use zone-aware types

DateTimeZone in PHP, ZonedDateTime in Java, aware datetimes in Python.

3

Serialise as ISO 8601

With an explicit Z or offset, never a bare local string.

4

Write transition tests

Assert correct behaviour on the last Sunday in March and October.

Questions people ask

UTC for anything that has happened. For future scheduled events, store the local time together with the IANA zone so a rule change does not move the event.

Keep reading

Daylight saving explained

Which countries change their clocks, when they do it, and why the same two cities can be five hours apart one week and six the next.

UTC, GMT and Zulu time

What UTC actually is, how it differs from GMT, why aviation says Zulu, and when the distinction matters.

Scheduling across time zones

A practical method for booking meetings across zones: finding the overlap, rotating the pain, and stopping recurring calls from drifting.

Check a UTC conversion

UTC pages for every major zone, with the offset stated explicitly.

Open the converters