📅 ISO 8601 Date Converter

Last updated: March 27, 2026

📅 ISO 8601 Date Converter

Convert between ISO 8601 strings, Unix timestamps, and local dates with timezone control.

Accepts Z (UTC), +HH:MM offset, or no offset (treated as UTC)

Enter seconds (10 digits) or milliseconds (13 digits)

ISO 8601 Dates, Unix Timestamps & Timezones: The Developer's Working Checklist

If you have ever stared at a backend response like 1705314600 and wondered whether that is a Unix timestamp in seconds or milliseconds — or received a date string like 2024-01-15T10:30:00+05:30 and needed to know what UTC time that equals — this guide is for you. ISO 8601 is the international standard for date and time representations, and understanding it properly removes an entire category of debugging headaches.

What ISO 8601 Actually Specifies

ISO 8601 is not a single format; it is a family of representations. The most common form you will encounter in APIs and databases is the combined date-time format: YYYY-MM-DDTHH:mm:ssZ. The T is a literal separator between the date and time portions. The trailing Z means UTC — shorthand for the +00:00 offset. A few things to check off:

  • Date-only strings like 2024-01-15 are valid ISO 8601. Most parsers treat them as midnight UTC, but some treat them as local midnight — a source of off-by-one-day bugs.
  • Week dates (2024-W03-1) and ordinal dates (2024-015) are also part of the standard, rarely seen outside specialised systems.
  • Duration strings like P1Y2M3DT4H are ISO 8601 too — useful in calendar and scheduling APIs.
  • The offset suffix is the most important part: +05:30 means "add 5 hours 30 minutes to local time to get UTC." Equivalently, "UTC minus 5:30 equals this local time."

Checklist: Reading Any ISO 8601 String Correctly

  1. Identify the offset. Z = UTC. A plus or minus followed by HH:MM is an explicit offset. No suffix at all usually means the string is "local" — avoid generating these; always include an offset or Z.
  2. Check for milliseconds. 2024-01-15T10:30:00.000Z — the .000 portion is optional but commonly included by JavaScript's Date.toISOString(). Parsers that expect exactly six characters after the decimal will choke on three.
  3. Beware the colon in offset. Some older systems write +0530 without the colon; RFC 3339 (the internet profile of ISO 8601) requires the colon. Always prefer the colon form.
  4. Convert to UTC first before storing or comparing. Two timestamps in different offsets cannot be compared as strings — convert both to UTC.

Unix Timestamps Demystified

A Unix timestamp counts seconds since the Unix Epoch: 1970-01-01T00:00:00Z. It is always UTC by definition — there is no timezone embedded in a Unix timestamp.

  • Seconds vs milliseconds: A 10-digit number like 1705314600 is seconds. A 13-digit number like 1705314600000 is milliseconds. JavaScript's Date.now() returns milliseconds; POSIX time() in C returns seconds. Mixing these is one of the most common timestamp bugs — multiplying a milliseconds value by 1000 gives a date in the year 56,000.
  • Maximum 32-bit Unix timestamp: 2147483647 — that is 2038-01-19T03:14:07Z, the famous Y2K38 problem. Systems still using 32-bit signed integers for timestamps will overflow on that date.
  • Negative timestamps are valid and represent dates before 1970. -1 is one second before the epoch.

Checklist: Storing and Transmitting Timestamps in APIs

  1. Always store UTC. Display timezones are a UI concern. Your database column should never contain 2024-01-15 16:00:00+05:30 — store 2024-01-15 10:30:00 (UTC) instead, or the Unix integer.
  2. Label your units. Name API fields created_at_unix_seconds or created_at_iso — not just ts or time. Future engineers (including yourself) will thank you.
  3. Include offset in API responses. If you return a local time, always include the offset. 2024-01-15T16:00:00 without a suffix is ambiguous.
  4. Avoid DST-sensitive formats. Timezone abbreviations like IST, EST, or PST are ambiguous (IST is Indian Standard Time, Israel Standard Time, and Irish Standard Time). Always use numeric offsets like +05:30 in machine-readable contexts.

Timezone Offsets: The Mental Model

A timezone offset describes the relationship between local time and UTC. The formula is always: Local time = UTC + Offset. So:

  • India Standard Time is UTC+5:30: if it is 10:30 UTC, it is 16:00 IST.
  • US Pacific Standard Time is UTC-8:00: if it is 10:30 UTC, it is 02:30 PST.
  • A string ending in +05:30 means you subtract 5 hours 30 minutes from the displayed time to get UTC.

Common Conversion Scenarios & Their Gotchas

Scenario 1: API returns a Unix timestamp in milliseconds, you need ISO 8601.
Divide by 1000 first, then construct a Date object. In JavaScript: new Date(ms).toISOString(). Forgetting to divide makes the year approximately 56,000.

Scenario 2: You need to display a UTC ISO string in a local timezone.
Parse the ISO string to a Date object (which stores UTC internally), then format it with the target offset. Do not use browser's toLocaleString() if you need the output to look the same across environments — it varies by browser locale.

Scenario 3: User enters a local date in a form; you need to store UTC.
Collect the date, time, and the user's timezone offset separately. Construct the full ISO string with the offset (2024-01-15T16:00:00+05:30), then parse it — the parser will correctly convert to UTC internally.

Scenario 4: Comparing two ISO strings from different offsets.
Never compare ISO strings lexicographically unless you are certain both are in UTC (ending in Z). Always convert to Unix timestamps (integers) and compare those.

Checklist: Before Shipping Date/Time Code

  1. Are all stored timestamps in UTC?
  2. Are all API timestamp fields clearly labelled as seconds or milliseconds?
  3. Are ISO strings always emitted with an explicit offset or Z suffix?
  4. Are date-only strings (YYYY-MM-DD) handled consistently — always as midnight UTC, not local midnight?
  5. Have you tested behaviour around DST transitions for any timezone-aware displays?
  6. Are timezone abbreviations replaced with numeric offsets in all machine-readable outputs?

Getting dates and times right is one of those areas where the "happy path" works immediately, but edge cases — DST transitions, leap seconds, different browser behaviours, 32-bit overflows — surface in production at the worst possible times. Using ISO 8601 consistently, converting everything to UTC at the boundary of your system, and being explicit about offsets in every string eliminates the majority of these problems before they start.

FAQ

What is the difference between ISO 8601 and Unix timestamp?
ISO 8601 is a human-readable text format for dates and times (e.g. 2024-01-15T10:30:00Z) that can include timezone offset information. A Unix timestamp is a plain integer counting seconds (or milliseconds) since 1970-01-01T00:00:00Z (the Unix Epoch) and is always implicitly UTC. Both represent the same moment in time; ISO 8601 is easier for humans to read, while Unix timestamps are simpler for arithmetic and storage.
What does the Z at the end of an ISO 8601 string mean?
The Z stands for 'Zulu time,' which is the military designation for UTC (Coordinated Universal Time). It is exactly equivalent to writing +00:00 as the offset. A string ending in Z, such as 2024-01-15T10:30:00Z, unambiguously represents a moment in UTC with no timezone conversion needed.
How do I tell if a Unix timestamp is in seconds or milliseconds?
Count the digits of the absolute value. A seconds-based timestamp for any date after 2001 has 10 digits (e.g. 1705314600). A milliseconds-based timestamp has 13 digits (e.g. 1705314600000). If you multiply a seconds timestamp by 1000 by mistake, the resulting date will be roughly in the year 56,000 — an easy sanity check. When in doubt, check if dividing by 1000 gives a plausible year.
Why should I avoid storing timezone abbreviations like IST or EST?
Timezone abbreviations are ambiguous. IST means Indian Standard Time (+05:30), Israel Standard Time (+02:00), and Irish Standard Time (+01:00 during summer). EST can mean US Eastern Standard Time (-05:00) or Australian Eastern Standard Time (+10:00). In any machine-readable or API context, always use numeric offsets like +05:30 or -05:00. Abbreviations are fine for human-facing labels only.
What happens when I parse a date-only ISO string like 2024-01-15?
Behaviour depends on the environment. The ECMAScript specification for JavaScript treats date-only strings (YYYY-MM-DD) as UTC midnight, which is a known footgun — if your user is in UTC-5, the displayed local date would show January 14th. Some older browsers treated them as local midnight. To avoid ambiguity, always include the time component and an explicit offset in any ISO string you generate programmatically.
What is the Y2K38 problem and which systems are affected?
The Y2K38 problem (also called the Unix Millennium Bug) affects systems that store Unix timestamps as 32-bit signed integers. The maximum value of a 32-bit signed integer is 2,147,483,647, which corresponds to 2038-01-19T03:14:07Z. After that second, the counter overflows to a large negative number, typically interpreted as December 13, 1901. Modern 64-bit systems are not affected, but embedded systems, legacy databases, and older file systems using 32-bit time fields remain at risk.