Timestamp Format Converter
The same instant has many written forms, and systems disagree about which one they accept. This page opens in format mode, showing an instant rendered several ways at once.
Which format to use where
- ISO 8601 - the default for APIs and log lines. Sorts correctly as a plain string, which is why it is worth preferring.
- With a Z suffix - explicitly UTC. Prefer this to an offset like +00:00 when a consumer might parse naively.
- Relative time - good for interfaces, wrong for storage, because it is only meaningful relative to when it was rendered.
- Epoch - compact and unambiguous for machines, unreadable for people, and silent about its unit.
The trap in ISO 8601
A timestamp with no zone designator is ambiguous, and parsers disagree about what to assume. Some treat it as UTC, some as local time, and the same string then means two different instants on two machines.
Always emit an explicit zone. A string like 2026-07-27T14:30:00 is an invitation to a bug that only appears in one deployment region.
2026-07-27T14:30:00Z unambiguous
2026-07-27T14:30:00+07:00 unambiguous
2026-07-27T14:30:00 ambiguousStore one form, render many
Keep the instant in a single canonical form - UTC - and format at the edge. Storing a formatted local string is how a record becomes impossible to compare against another one written in a different zone.
Week numbers and ordinal dates
ISO 8601 also defines week-based dates, where the year belongs to the week rather than the calendar. Around New Year the ISO week year can differ from the calendar year, which breaks naive reporting that mixes the two.
If a dashboard shows a stray week in the wrong year every January, this is why.