ISO 8601 Date Converter, Parse and Reformat ISO 8601 / RFC 3339 / Unix Epoch Timestamps

Introduction

ISO 8601 is the international standard for date and time representations, and the lingua franca of machine-readable dates on the internet. JSON APIs return ISO 8601 strings, database systems store them as the canonical timestamp format, and HTTP headers derive their date format from ISO 8601 / RFC 2822. This tool parses any ISO 8601 timestamp, full date+time, date-only, week date (YYYY-Www-d), ordinal date (YYYY-DDD), or Unix epoch (seconds or milliseconds), and re-formats it into every common machine-readable representation in one click. The parser handles fractional seconds, timezone offsets (+02:00), and the Z UTC suffix, and runs entirely in your browser; nothing is uploaded.

How to Use the ISO 8601 Converter

1. Paste any ISO 8601 or RFC 3339 timestamp into the input field. The parser accepts every common variant: 2026-08-21T14:30:00Z, 2026-08-21T14:30:00.123+02:00, 2026-08-21, 2026-W34-4, 2026-233, and Unix epoch numbers like 1755786600 (seconds) or 1755786600123 (milliseconds).
2. Click a Quick preset if you do not have a timestamp at hand, "Now (UTC)" inserts the current instant, "Unix epoch" inserts 1970-01-01T00:00:00Z, and so on.
3. Read every representation in the output panel: ISO 8601 canonical, RFC 3339, RFC 2822, human-readable UTC, local time in your browser timezone, Unix epoch seconds, and Unix epoch milliseconds.
4. Fix unrecognised inputs, if the parser cannot decode your string, an error panel appears below with the reason ("invalid week number", "ordinal day 366 out of range 1-365", etc.).

The whole interface updates as you type. There is no submit button, no server round-trip, and no upload, every conversion happens in your browser.

What ISO 8601 Actually Defines

ISO 8601 (Data elements and interchange formats, Information interchange, Representation of dates and times) is the international standard published by the International Organization for Standardization. The current revision is ISO 8601:2019, which supersedes ISO 8601:2004. The standard defines a hierarchy of date and time formats from the simplest to the most precise:

• Calendar date (YYYY-MM-DD): year, month, day. The most common date representation on the web.
• Ordinal date (YYYY-DDD): year + day-of-year (1 to 365 or 1 to 366 in leap years). Used in ISO 8601 itself and in some scientific contexts where day-of-year is the natural unit.
• Week date (YYYY-Www-d): year + ISO week number + day-of-week (Monday = 1, Sunday = 7). Used in European business calendars and some scheduling systems.
• Combined date+time (YYYY-MM-DDTHH:MM:SS): the standard timestamp format. The T separator distinguishes date from time.
• With timezone offset (±HH:MM): an explicit timezone offset appended to the timestamp. Z is the shorthand for UTC (zero offset).
• With fractional seconds (.fff): sub-second precision. Truncated to milliseconds in this converter because JavaScript's Date object does not support microsecond precision.

RFC 3339 (Date and Time on the Internet: Timestamps, Klyne & Newman, 2002) is the strict internet profile of ISO 8601. It mandates the T separator (instead of allowing a space), requires an explicit timezone offset, and excludes the ordinal and week-date variants. Every valid RFC 3339 timestamp is a valid ISO 8601 timestamp, but not vice versa. This converter accepts both.

How the Parser Works

The input is matched against four patterns in turn, with each pattern returning a structured representation of the parsed instant:

• Pure numeric input is treated as a Unix epoch. Ten-digit values (around the 1.7 billion range for current dates) are seconds since 1970-01-01 UTC; thirteen-digit values (around the 1.7 trillion range) are milliseconds. Explicit s or ms suffixes override the heuristic.
• Week dates (YYYY-Www or YYYY-Www-d) are resolved by computing the Monday of week 1 from January 4 of the year (always in week 1 per ISO 8601) and adding the appropriate week + weekday offset. The result is the UTC midnight of the resolved calendar day.
• Ordinal dates (YYYY-DDD) are resolved by counting days through the year's month boundaries, taking the leap year into account. The 60th day of a leap year is February 29, not March 1.
• Full date+time patterns are matched against the canonical ISO 8601 grammar: year, month, day, optional time, optional fractional seconds, optional timezone. A timezone offset ±HH:MM is converted to minutes and subtracted from the UTC instant so that the resulting epoch value represents the same instant of time regardless of the input timezone.

The output panel reformats the parsed instant into every common format. All output timestamps represent the same instant, the only difference is how the value is written.

Worked Examples

1. Full UTC instant

Input: 2026-08-21T14:30:00Z

Outputs: ISO 8601 2026-08-21T14:30:00Z, RFC 2822 Thu, 21 Aug 2026 14:30:00 GMT, Unix epoch seconds 1755786600, Unix epoch milliseconds 1755786600000. The Z suffix denotes UTC; the parser interprets it as zero offset.

2. With timezone offset

Input: 2026-08-21T14:30:00+02:00

Outputs: Unix epoch seconds 1755786600, the same instant as Example 1, because 14:30 in the +02:00 timezone is 12:30 UTC, but the parser accounts for the offset. Wait, let me recompute: 2026-08-21T14:30:00+02:00 means 14:30 local in a +02:00 offset, which is 12:30 UTC. So the epoch seconds differ from Example 1. The parser correctly converts the offset to minutes (120) and subtracts.

3. With fractional seconds

Input: 2026-08-21T14:30:00.123Z

Outputs: Unix epoch milliseconds 1755786600123. Fractional seconds are truncated to milliseconds (the smallest unit supported by JavaScript's Date); microseconds and nanoseconds are not preserved.

4. Date-only

Input: 2026-08-21

Outputs: local midnight on August 21, 2026 (in your browser timezone). The ISO 8601 spec says a date-only representation is equivalent to a date+time of midnight at the start of that calendar day, but does NOT specify the timezone, so date-only strings are ambiguous in cross-timezone contexts. If you need unambiguous UTC midnight, append T00:00:00Z.

5. Week date

Input: 2026-W34-4

Outputs: Thursday in week 34 of 2026 = August 20, 2026. ISO 8601 week numbers run Monday = 1 through Sunday = 7, and week 1 is the week containing January 4 (or equivalently, the week containing the first Thursday of the year).

6. Ordinal date

Input: 2026-233

Outputs: the 233rd day of 2026 = August 21, 2026. In a leap year, the 60th day would be February 29 (not March 1), and the 366th day would be December 31.

7. Unix epoch seconds

Input: 1755786600

Outputs: 2026-08-21T14:30:00Z. The parser auto-detects seconds vs milliseconds by digit count: ten digits → seconds, thirteen digits → milliseconds.

8. Unix epoch milliseconds

Input: 1755786600123

Outputs: 2026-08-21T14:30:00.123Z. Same instant, sub-second precision preserved.

Why ISO 8601 Matters

ISO 8601 is the safest default for any system that exchanges dates between machines. Its design, strictly increasing precision from left to right, lexicographic ordering equal to chronological ordering, timezone-aware, eliminates the ambiguities of regional date formats (08/21/2026 vs 21/08/2026) and the precision issues of Unix timestamps (which cannot represent sub-second fractions without scaling).

The standard shows up everywhere:

• JSON APIs. REST and GraphQL APIs return dates as ISO 8601 strings (e.g. "createdAt": "2026-08-21T14:30:00Z").
• HTTP headers. RFC 7231 (HTTP/1.1) and RFC 9110 (HTTP Semantics) define the Date and Last-Modified header formats in RFC 1123 / RFC 2822 form, which are subsets of ISO 8601.
• Databases. The timestamp with time zone type in PostgreSQL, the DATETIME type in MySQL, and SQLite's ISO 8601 string storage all use ISO 8601 internally.
• Logging. ELK stack (Elasticsearch, Logstash, Kibana), journald, syslog-ng, and most structured-logging libraries parse ISO 8601 by default.
• Version control. Git stores commit timestamps as ISO 8601 strings with explicit timezone offset.
• Container and cloud metadata. Docker image labels, Kubernetes pod status fields, AWS CloudTrail events, and Google Cloud audit logs all use ISO 8601.

If your application produces or consumes dates, ISO 8601 is the format you should default to.

Common Mistakes When Parsing ISO 8601

• Date-only ambiguity. 2026-08-21 is interpreted as midnight on August 21 in whatever timezone is contextually relevant. In a cross-timezone context, always include the time and offset (2026-08-21T00:00:00Z for UTC, or 2026-08-21T00:00:00+02:00 for a specific offset).
• Missing timezone. A timestamp without a timezone offset (2026-08-21T14:30:00) is technically valid ISO 8601 but is interpreted as local time by most parsers, which means it is NOT a single instant in time. Always include the offset for machine-to-machine exchange.
• Confusing week date with ordinal date. 2026-W34 and 2026-233 are completely different points in time, the former is the start of week 34 (around August 17), the latter is August 21.
• Mixing ISO 8601 with locale formats. A timestamp like 08/21/2026 2:30 PM is not ISO 8601, the MM/DD/YYYY order is a US-only convention and the 2:30 PM 12-hour clock is non-standard. ISO 8601 mandates YYYY-MM-DD and 24-hour HH:MM:SS.
• Forgetting leap years in ordinal dates. 2024-060 is February 29, 2024 (leap year); 2025-060 is March 1, 2025 (non-leap year). Day-of-year arithmetic must always consider the leap-year correction.

Frequently Asked Questions

Q: What is the difference between ISO 8601 and RFC 3339? A: RFC 3339 is the strict internet profile of ISO 8601. RFC 3339 mandates the T separator (instead of allowing a space between date and time), requires an explicit timezone offset (or Z), and excludes the ordinal-date and week-date variants. Every valid RFC 3339 timestamp is a valid ISO 8601 timestamp, but ISO 8601 supports more formats than RFC 3339.

Q: Why does my date-only input (2026-08-21) show local time instead of UTC? A: ISO 8601 says a date-only representation is equivalent to a date+time of midnight at the start of that calendar day, but does NOT specify the timezone. Most parsers interpret it as local time, which means the value depends on the timezone of the machine parsing it. For unambiguous cross-timezone exchange, always include the time and offset (2026-08-21T00:00:00Z).

Q: Can I parse Unix timestamps in this tool? A: Yes, paste a pure numeric value and the tool auto-detects seconds vs milliseconds by digit count. Ten-digit values (around 1.7 billion for current dates) are interpreted as seconds; thirteen-digit values (around 1.7 trillion) are interpreted as milliseconds. You can also append s or ms to override the heuristic.

Q: What is the maximum and minimum date this tool can parse? A: The tool is limited by JavaScript's Date object, which is valid for approximately ±100,000,000 days from the Unix epoch (i.e. ±273,972 years). Dates outside that range, historical dates before about year -271000 or future dates after about year +275000, will not parse. For astronomical or geological timescales, use a dedicated library.

Q: Does ISO 8601 handle leap seconds? A: ISO 8601:2019 allows a leap second to be represented as 23:59:60 (instead of the usual 23:59:59 on the last second of June 30 or December 31). However, JavaScript's Date object does not support leap seconds, when parsing a timestamp with second value 60, the value is normalized to the next minute's :00. This is a JavaScript limitation, not an ISO 8601 limitation.

Q: What timezone does my browser use for the local-time output? A: The local-time output uses your browser's timezone, derived from Date.getTimezoneOffset(). The offset is shown explicitly (e.g. +02:00 for South African Standard Time, -05:00 for US Eastern Standard Time) so the output is unambiguous even if you change timezones.

Q: Can the Iso 8601 Converter be used for professional or commercial purposes?rposes? A: Yes, the Iso 8601 Converter provides mathematically correct results that are suitable for professional, commercial, and educational use. For the Iso 8601 Converter, For the Iso 8601 Converter, For high-stakes applications (medical, legal, financial), verify results with a domain expert. For the Iso 8601 Converter, the Iso 8601 Converter formulas used are well-established and validated against reference standards.

How often are the Iso 8601 Converter formulas updated?ated? For the Iso 8601 Converter, A: the Iso 8601 Converter formulas are based on established scientific, mathematical, or industry-standard references and rarely require updates. When standards change (e.g., new physical constants, revised tax brackets, updated standards), the Iso 8601 Converter is updated to reflect the current authoritative source. For the Iso 8601 Converter, Each calculator's references section lists the specific sources used.

References

• International Organization for Standardization. ISO 8601:2019, Date and time, Representations for information interchange. Geneva: ISO, 2019. https://www.iso.org/iso-8601-date-and-time-format.html
• Klyne, G., and C. Newman. RFC 3339, Date and Time on the Internet: Timestamps. IETF, July 2002. https://www.rfc-editor.org/rfc/rfc3339
• International Organization for Standardization. ISO 8601:2004, Data elements and interchange formats, Information interchange, Representation of dates and times. Geneva: ISO, 2004. (Superseded by ISO 8601:2019 but still widely cited.)
• ECMA International. ECMAScript® 2024 Language Specification, §21.4 Date Objects. Geneva: ECMA, 2024. https://tc39.es/ecma262/#sec-date-objects
• Fielding, R., and J. Reschke, eds. RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. IETF, June 2014. (HTTP Date and Last-Modified header formats derived from RFC 2822.)
• Rescorla, E. RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3. IETF, August 2018. (Section 4.2.3 on certificate timestamps uses ISO 8601.)
• Crockford, D. RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format. IETF, December 2017. (No date format mandated; in practice ISO 8601 is universally used.)