Developer & system utilities
ISO 8601 generator & decoder
Read a timestamp or write one. Decode any ISO 8601 / RFC 3339 string into Unix, UTC, and local time, or build a strict ISO string from a date — copy-ready.
Decode a timestamp
Enter a valid ISO 8601 / RFC 3339 string.
Generate from a date
Pick a date and time.
How to use the iso 8601 generator & decoder
Build a timestamp
Set a date, a time and a zone, and get a valid ISO 8601 string with the correct offset suffix.
Decode one you have
Paste an existing string to see the instant it denotes, what each component means, and whether it is actually well-formed.
Choose Z or an offset
A trailing Z means UTC. An offset like +05:30 preserves the local reading as well as the instant. Both are valid; pick based on whether the local wall-clock time carries meaning.
Copy it into your code
The output parses cleanly in every mainstream language and database without a custom format string.
ISO 8601 and why it is the format to standardise on
ISO 8601 writes a timestamp as 2026-07-25T14:30:00Z: year, month, day, a T separator, then the time and a zone designator. Its defining property is that lexicographic order matches chronological order — sorting the strings sorts the instants — which makes it uniquely convenient for filenames, log lines and database keys.
It also solves the ordering ambiguity that causes real damage. 03/04/2026 is 3 April in most of the world and 4 March in the United States, and there is no way to tell which was meant from the string alone. Big-endian ordering, largest unit first, has no such failure mode, which is why the format is mandated in aviation, finance and most engineering standards.
The zone designator is the part people get wrong. A string with no zone at all is a local time whose meaning depends on who reads it — avoid it in anything transmitted or stored. Z means UTC and is the right default for machine data. An explicit offset like +09:00 is right when the local reading itself matters, such as when recording the wall-clock time a user saw.
Note the limit of an offset, though: it records what the offset was, not which zone it belonged to. For a future event you also need the IANA zone name, because the offset that will apply on that date may not be the one that applies today. Storing both — the instant and the zone — is the pattern that survives rule changes.
When you'd reach for it
API design
Standardise every timestamp field on a format that parses everywhere without ambiguity.
Log formats
Emit sortable timestamps so ordering and grepping by prefix both work.
Filenames for backups
Name files so an alphabetical listing is also chronological.
Database columns
Choose between a UTC instant and an offset-bearing value for a schema.
Validating input
Check whether a string you have been sent is actually well-formed ISO 8601.
Documentation examples
Write sample payloads that an international audience reads identically.
Questions & answers
- What is ISO 8601?
- An international standard for writing dates and times unambiguously, like 2026-07-24T13:00:00Z. The trailing Z means UTC; an offset such as +01:00 places it in a specific zone.
- What's the difference from RFC 3339?
- RFC 3339 is a tightened profile of ISO 8601 used across internet protocols. Most RFC 3339 strings are valid ISO 8601, and this tool reads and writes both.
- Why offer 'with offset' and 'UTC' versions?
- The UTC (Z) form is best for storage and APIs; the offset form preserves the local wall-clock and zone, which matters for human-facing timestamps.