Skip to content
FindTool

    ISO Date Converter

    Parse and build ISO 8601 / RFC 3339 dates and convert between common formats.

    ISO Date Converter tool

    Parse a date


    Build an ISO string

    Result
    —

    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 timestamptz dump 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.RFC3339 or a JSON Schema format: 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.