ISO 8601 Converter

ISO 8601 is the standard way to write dates and times in a sortable, unambiguous string — for example a full datetime ending in Z for UTC. APIs, JSON documents, and logs prefer ISO forms because they avoid locale month/day swaps. This ISO 8601 converter helps you parse common ISO and RFC 2822-style inputs into normalized UTC output and related Unix seconds for debugging.

When to use ISO conversion

Use it when an API returns a timestamp you need to verify, when email headers show RFC 2822 dates, or when you must compare a human date with a machine string. Backend developers check serialization round-trips. Support teams translate customer screenshots into UTC. If you start from Unix epoch integers, open Unix timestamp. Spreadsheet serials belong on Excel date converter.

Windows ticks belong on FILETIME. ISO strings are the safest default when exporting events for other systems — prefer them over ambiguous numeric dates that mean different days in the US and Europe.

What good ISO strings look like

A full datetime should include a date, a time, and a zone designator. Z means UTC. Offsets like −05:00 state civil offset from UTC. Date-only forms (YYYY-MM-DD) are allowed in ISO 8601 but represent a calendar day, not a single instant — interpret them carefully in global apps. Week dates and ordinal dates exist in the standard; this site also offers dedicated ordinal date and week-number tools for those variants.

RFC 2822 (email) uses a different textual style but represents similar instants. Converters that accept both save time when jumping between mail headers and JSON APIs without manual reformatting.

How to use this page

Paste an ISO or RFC-style datetime, or pick a calendar date when you only need a day anchor. Calculate to see ISO 8601, RFC 2822, and Unix seconds representations. Use the outputs in docs, tests, and tickets. Keep zone information explicit when you paste results into chat or incident threads.

When generating strings in code, always include an offset or Z. Naked local datetimes without zone data are a leading cause of production bugs around daylight saving weekends when servers and browsers disagree about the offset.

DST, sorting, and storage choices

Civil offsets change when regions observe daylight saving. A meeting stored with a numeric offset may need care near fall-back if local clocks repeat an hour — prefer storing UTC instants and formatting for display. Lexical sorting of zero-padded ISO datetimes in UTC works well; sorting mixed offsets as plain strings is unreliable — normalize to UTC first.

Confirm upcoming DST changes with the daylight saving time tool when scheduling across transitions. Leap seconds are rare in business apps; most systems ignore them and use Unix time approximations that are good enough for billing and analytics.

Worked example

An API returns a UTC instant ending in Z. Paste it here to confirm Unix seconds and a friendly UTC string. Convert for a local reader using event time or the world clock when you need wall time in another city. Document both the ISO instant and the local display in the ticket so future readers do not re-derive zones incorrectly.

For 2026 release notes, publish go-live times as ISO UTC plus one local example city. Pair with a countdown only for human-facing remaining time, not as the authoritative source of truth.

API and log hygiene

Store instants in UTC at the database layer and render ISO with offset at the edge. Log lines should include zone or Z so grep results sort chronologically without ambiguity. When migrating legacy CSV files, convert ambiguous US-style dates through this tool once, then ban locale-dependent formats in new exports.

Round-trip encode and decode after library upgrades. Any drift usually means a timezone or epoch assumption changed in your serializer. Keep a fixture file with three known strings: date-only, offset datetime, and Zulu instant.

JSON APIs and database columns

REST and GraphQL payloads often serialize instants as ISO strings or Unix numbers in adjacent fields. When debugging a mismatch, paste the ISO form here and compare Unix seconds to the API’s numeric field. ORMs sometimes strip milliseconds or offsets during save — the converter helps you see what was lost between request and persistence layers.

PostgreSQL timestamptz and MySQL datetime columns behave differently on insert. ISO strings with Z should map cleanly to UTC storage; strings without zones depend on session timezone settings that vary by connection pool. Normalize in application code and treat this page as a manual oracle when staging rows look shifted by one hour near DST.

Email forensics and log aggregation

Message headers carry Received lines in RFC 2822 format while JSON log shippers emit ISO. Paste each into this tool to align a phishing timeline with firewall logs. Support engineers triaging “wrong timezone on receipt” tickets can prove whether the bug is display formatting or actual storage offset.

Centralized log platforms that index strings lexically benefit from upstream normalization to UTC ISO before ingest. If that step is missing, use this converter on sample lines to design a parser fix rather than guessing offset arithmetic in Kibana or Splunk queries alone.

Publishing and release coordination

Product marketing often wants a friendly local time while engineering publishes UTC in status pages. Generate both from one paste: ISO Z for the runbook, then event time for the blog post hero. Consistent source instant prevents social posts from going live an hour early relative to the API flag flip.

Contractual SLA reports that cite “incident start in ISO 8601” should attach the exact string from monitoring, not a retyped shorthand. Retyping invites transposed digits in month fields — paste through this tool to validate before legal review.

Related tools

Browse the converters hub for epoch, FILETIME, cron, and calendar converters. Civil planning: date tools hub. Clocks and meeting overlap: time tools hub and meeting planner.