ISO Date Converter
Parse and build ISO 8601 / RFC 3339 dates and convert between common formats.
ISO Date Converter tool
Parse a date
| How it was read | — | |
|---|---|---|
| ISO 8601 (UTC) | — | |
| ISO 8601 (your offset) | — | |
| RFC 3339 | — | |
| RFC 2822 | — | |
| ISO basic format | — | |
| ISO week date | — | |
| ISO ordinal date | — | |
| Unix seconds | — | |
| Unix milliseconds | — | |
| Readable | — |
Build an ISO string
What this tool does
Paste a date in almost any shape — an ISO string, an email header date, a bare epoch number, something a database printed — and this page tells you which instant it names and rewrites it in every format you are likely to need. It also works the other way: set the components, choose an offset, and get a string a strict RFC 3339 parser will accept.
It never silently guesses about the offset. If your input has no Z and no
+hh:mm, the page says so and shows which zone it assumed, because that one
decision is what moves a date by up to 26 hours.
Common uses
- Turning a database
timestamptzdump into a value an API will accept. -
Checking whether a string is genuinely RFC 3339 before sending it to a strict parser such
as Go's
time.RFC3339or a JSON Schemaformat: date-time. - Working out which ISO week a date falls in for a reporting query.
A short example
Input:
Tue, 14 Nov 2023 22:13:20 +0000 Output:
ISO 8601 (UTC) 2023-11-14T22:13:20.000Z
ISO basic 20231114T221320Z
ISO week date 2023-W46-2
ISO ordinal 2023-318
Unix seconds 1700000000 Z, +00:00, and the difference between ISO 8601 and RFC 3339
Z is short for "Zulu", the military name for the zero meridian. In
2026-09-24T14:30:05Z it means the offset from UTC is zero. Writing
+00:00 names the same instant, so the two are interchangeable for arithmetic
— but RFC 3339 §4.3 draws a distinction of intent: -00:00 is reserved for
"this is UTC, and the local offset is unknown", whereas +00:00 asserts the
local offset genuinely is zero. A real offset such as +02:00 carries more
still: it pins the instant and records what the clock said locally, which is why
it beats 12:30:05Z in an audit trail.
RFC 3339 is a deliberately narrow profile of ISO 8601 for the internet. It requires a full
date and time, requires an offset, and forbids most of ISO 8601's flexibility — no week
dates, no ordinal dates, no omitted fields, no 20260924T143005 basic format.
Practically everything RFC 3339 accepts is valid ISO 8601; a great deal of valid ISO 8601
is not valid RFC 3339. RFC 3339 does permit a space in place of T by explicit
agreement (§5.6); ISO 8601 does not.
Worth knowing
Offsets are not timezones. +02:00 says the clock was two hours ahead of UTC at
that moment; it does not say whether that was Berlin in summer or Cairo in winter, and it
cannot say what the offset will be next March. For anything scheduled in the future, store
the IANA zone name — Europe/Berlin — alongside the local time, because
governments change DST rules with weeks of notice. An offset is right for an event that has
already happened; a zone name is right for one that has not.
Frequently asked questions
Why does a date-only string come out a day early in JavaScript?
ECMA-262 treats the two shapes differently. A bare 2026-03-01 is parsed as midnight UTC, whereas the same value with a time and no offset, 2026-03-01T00:00, is parsed as midnight local. Format the first one in any zone behind UTC and it prints as 28 February. The cure is to stop leaving it implicit: attach the offset, or build the value from components in the zone you actually mean.
Can I sort ISO 8601 strings as plain text?
Yes, as long as every value is UTC and identically shaped, because the format is big-endian and zero-padded. It fails the moment shapes vary: mixed offsets sort by local wall clock rather than by instant, and 2026-01-01T00:00:00Z sorts after 2026-01-01T00:00:00.000Z despite naming the same moment, since a full stop is byte 0x2E and Z is 0x5A. Normalise to UTC with a fixed number of fractional digits first.
Is 23:59:60 or 24:00 a valid time?
The two specifications split on this. RFC 3339 allows a seconds value of 60 so that a leap second such as 1998-12-31T23:59:60Z can be written down, and its grammar caps the hour at 23, making 24:00 invalid. ISO 8601 does the opposite for midnight, where 24:00 legitimately means the end of a day. Parsers are unforgiving — Go’s time.Parse rejects hour 24 outright — so keep both out of anything you exchange.