ISO 8601 Date Converter

About ISO 8601 Date Converter

ISO 8601 is the international standard for writing dates and times from the largest unit to the smallest: year-month-day, a T, hours:minutes:seconds, and an offset from UTC, as in 2026-09-22T09:00:00+09:00. This converter takes a string like that, or a Unix timestamp, and gives you the UTC form, the same instant at an offset you choose, the timestamp in seconds and milliseconds, and the ISO weekday number.

The offset is what makes a timestamp unambiguous. Without one, 2026-09-22T09:00 is just “9 o'clock somewhere,” and the tool reads it as 9 o'clock at the offset selected below the input.

ISO 8601 versus RFC 3339

When API documentation says “ISO 8601,” it almost always means RFC 3339, a narrow Internet profile of ISO 8601. RFC 3339 requires a four-digit year, all fields down to seconds, and an offset (Z or ±hh:mm). JSON Schema's date-time format, many cloud APIs, and Atom feeds point to it.

ISO 8601 itself is much broader. The basic format without separators (20260922T090000Z), week dates (2026-W39-2), ordinal dates (2026-265), times truncated to minutes, durations (P1M) and intervals are all valid ISO 8601 but not RFC 3339 timestamps. RFC 3339, for its part, lets applications use a space instead of T for readability and reserves -00:00 to say “UTC time, local offset unknown.” The form that satisfies both is the plain one: 2026-09-22T00:00:00Z.

This tool reads the extended format (with hyphens and colons), date-only or date-plus-time. Besides calendar dates it reads week dates (2026-W39-2; without the weekday digit, Monday), ordinal dates (2026-265) and the basic format (20260922T090000Z). It accepts a space instead of T, a colonless offset like -0500 or -05, and lowercase z. A bare string of digits such as 20260922 or 2026265 is read as a Unix timestamp, so for a basic-format date alone add hyphens or a time (T0000). A duration such as P1M gets a message saying it is a length of time, not a point in time; a leap second (:60) is still rejected. Fractional seconds up to nine digits are accepted and cut to milliseconds.

Week dates: when is 2026-W39?

ISO weeks start on Monday, and week 1 is the week containing the year's first Thursday (equivalently, the week containing January 4). January 1, 2026 is a Thursday, so 2026-W01 begins on Monday, December 29, 2025. Add 38 weeks and 2026-W39 runs from Monday, September 21 to Sunday, September 27; Tuesday, September 22 is 2026-W39-2. The ISO weekday shown by the tool is that final digit.

Year boundaries are where this bites. Because 2026 starts on a Thursday, it has 53 ISO weeks, and Friday, January 1, 2027 is 2026-W53-5, not part of 2027. Excel's default WEEKNUM and the common U.S. convention (weeks start Sunday, week 1 contains January 1) number weeks differently; ISOWEEKNUM in Excel follows ISO. If a European supplier quotes “delivery in week 39” and your calendar app is set to U.S. week numbers, check which week they mean.

How long is P1M?

ISO 8601 durations start with P and split date and time parts with T: P1Y2M10DT2H30M is one year, two months, ten days, two hours and thirty minutes; PT36H is 36 hours. The letter M means months before the T and minutes after it, so P1M is a month and PT1M is a minute. That single character causes a surprising number of bugs in cache and token expiry settings.

P1M has no fixed length. Added to January 15 it's 31 days; added to February 15 it's 28. January 31 plus P1M isn't defined by the standard, and libraries differ: some clamp to February 28, others roll over into March. Across a U.S. daylight-saving change, P1D (same wall-clock time tomorrow) and PT24H (exactly 24 hours later) land an hour apart. When a duration decides a billing date or a subscription renewal, test what your library actually does. This converter doesn't do duration arithmetic; the date calculator handles adding calendar months.

An offset is not a time zone

-04:00 states one fact: at this instant, local time is four hours behind UTC. A time-zone name from the IANA database, such as America/New_York or Europe/London, is the full history and future of a region's offsets, including daylight-saving rules. New York is -04:00 in summer and -05:00 in winter.

Suppose in September you store a meeting for “November 10 at 9 a.m. in New York” as 2026-11-10T09:00:00-04:00. U.S. daylight saving time ends on November 1, 2026, so New York is at -05:00 that day and the stored instant is 8 a.m. local. Future local events should be stored as local time plus zone name. RFC 9557 (2024) standardizes a suffix for exactly this: 2026-11-10T09:00:00-05:00[America/New_York], and JavaScript's Temporal API uses the same notation. The offset picker in this tool is a fixed offset; it knows nothing about DST, so choose the offset that applies on the date you're converting.

The picker includes the unusual offsets real places use: +05:30 (India), +05:45 (Nepal), +09:30 (South Australia's winter offset), +12:45 (New Zealand's Chatham Islands in winter). Not every offset is a whole hour.

Worked examples

How to use it

1. Paste an ISO 8601 string or Unix timestamp, or pick a date and time.
2. Choose the display offset, or press “Use my timezone.”
3. Copy the UTC, offset or timestamp result you need.

Frequently asked questions