ISO 8601 — the only date format you should ever use
If you've ever spent a frustrating hour figuring out whether `01/02/2026` means January 2 or February 1, you've encountered why ISO 8601 exists. It's the international standard for representing dates and times in a way that's unambiguous regardless of culture, language, or system.
For converting between ISO 8601 and Unix epoch timestamps, the epoch converter handles them.
The basic format
ISO 8601 dates look like:
```
YYYY-MM-DD (date only)
2026-05-21
2026-12-25
```
ISO 8601 datetimes:
```
YYYY-MM-DDTHH:MM:SS (no time zone — local time)
2026-05-21T14:30:00
YYYY-MM-DDTHH:MM:SSZ (UTC)
2026-05-21T14:30:00Z
YYYY-MM-DDTHH:MM:SS+HH:MM (with offset)
2026-05-21T14:30:00+05:30
2026-05-21T14:30:00-05:00
```
Year, month, day. Then 'T' separator. Then hour, minute, second. Then 'Z' for UTC or an offset.
Why this format wins
Three reasons it's the right default:
1. Sortable. ISO 8601 dates sort correctly by simple alphabetical/lexicographic sort. `2025-12-31` sorts after `2025-01-15` because string comparison happens left-to-right and "12" > "01" in string terms (and "5" > "1" before that). This is rare among date formats — the European DD-MM-YYYY and US MM/DD/YYYY both fail this test.
2. Unambiguous. `2026-05-21` is May 21, 2026. There's no ambiguity. Any system in the world that follows the standard interprets this the same way. Compare with `5/21/26` (US, May 21) or `21/5/26` (Europe, May 21) or `26/5/21` (Japan in some contexts) — these can all mean different things.
3. Universal support. Every modern programming language, database, and API supports ISO 8601 natively. JavaScript's `Date.toISOString()`, Python's `datetime.isoformat()`, PostgreSQL's `to_char()`, all output ISO 8601 by default.
The full format spec
ISO 8601 supports several optional precision levels:
```
YYYY-MM-DD (date)
YYYY-MM-DDTHH (date + hour)
YYYY-MM-DDTHH:MM (date + hour:minute)
YYYY-MM-DDTHH:MM:SS (date + hour:minute:second)
YYYY-MM-DDTHH:MM:SS.sss (with milliseconds)
YYYY-MM-DDTHH:MM:SS.ssssss (with microseconds)
YYYY-MM-DDTHH:MM:SS.sssssssss (with nanoseconds)
```
Time zones can be:
```
Z (UTC, "Zulu")
+HH:MM (offset ahead of UTC)
-HH:MM (offset behind UTC)
+HHMM (no colon) (also valid)
+HH (just hours) (also valid)
```
Examples:
- `2026-05-21T14:30:00Z` — UTC time
- `2026-05-21T20:00:00+05:30` — India time (UTC+5:30) at 8 PM
- `2026-05-21T07:30:00-07:00` — Pacific time at 7:30 AM
Common variants and extensions
ISO 8601 ordinal date format: `2026-141` (May 21, the 141st day of 2026). Used in some scientific contexts, less common in everyday use.
ISO 8601 week date format: `2026-W21-3` (Wednesday of week 21, 2026). Used in some European contexts, especially industrial/manufacturing.
ISO 8601 time intervals: `P3Y6M4DT12H30M5S` (a duration of 3 years, 6 months, 4 days, 12 hours, 30 minutes, 5 seconds). Used in scheduling contexts.
For most everyday use, the basic YYYY-MM-DD and full datetime formats are all you need.
How to handle time zones
ISO 8601 has three approaches:
Approach 1: Always UTC. Every timestamp ends in 'Z' (or `+00:00`). Recommended for storage. Convert to local time only at the display layer.
```
2026-05-21T14:30:00Z
```
Approach 2: Local time with offset. Each timestamp includes the offset. Useful when the time-of-day in a specific zone matters.
```
2026-05-21T20:00:00+05:30 (8 PM in India)
```
Approach 3: Local time without offset. Just `YYYY-MM-DDTHH:MM:SS`. Ambiguous about time zone. Use only when context makes the zone clear (e.g., a document specifying local time).
```
2026-05-21T20:00:00 (some local time, you have to know which)
```
For storage and APIs: prefer Approach 1 (UTC) or Approach 2 (with offset). Avoid Approach 3 for anything that crosses systems.
Common mistakes
Putting space instead of 'T'. `2026-05-21 14:30:00` is technically valid but the 'T' separator is preferred. Most parsers accept both.
Inconsistent precision. Don't mix `YYYY-MM-DDTHH:MM:SS` and `YYYY-MM-DDTHH:MM:SS.sssZ` in the same dataset. Pick a precision and stick with it.
Confusing offset format. Use `+HH:MM` (with colon). `+0530` (without colon) is valid but less common. Don't write `+5:30` (single-digit hour) — always use `+05:30`.
Time zone abbreviation in ISO 8601. Don't write `2026-05-21T14:30:00 EDT`. ISO 8601 only supports numeric offsets (`-04:00`) or 'Z'. Time zone names belong in IANA syntax, separate from ISO 8601 timestamps.
Half-day formatting in 24-hour mode. `2026-05-21T2:30:00` (1-digit hour) is technically valid but less common. Always use 2-digit hours: `02:30:00`.
ISO 8601 in different languages
```javascript
// JavaScript
const now = new Date();
const iso = now.toISOString();
// Output: "2026-05-21T14:30:00.000Z"
```
```python
Python
from datetime import datetime, timezone
iso = datetime.now(timezone.utc).isoformat()
Output: "2026-05-21T14:30:00.000000+00:00"
```
```ruby
Ruby
Time.now.utc.iso8601
Output: "2026-05-21T14:30:00Z"
```
```go
// Go
time.Now().UTC().Format(time.RFC3339)
// Output: "2026-05-21T14:30:00Z"
```
```sql
-- PostgreSQL
SELECT to_char(NOW() AT TIME ZONE 'UTC', 'YYYY-MM-DD"T"HH24:MI:SSZ');
-- Output: "2026-05-21T14:30:00Z"
```
All major languages and databases produce ISO 8601 output natively.
When to deviate
A few cases where you might use other formats:
User-facing display. "May 21, 2026" or "21 May 2026" is more readable than "2026-05-21" for end users. ISO 8601 is for storage and APIs, not always for display.
Writing dates in prose. "May 21, 2026" reads more naturally in an article than "2026-05-21." Use ISO 8601 in code; use prose dates in writing.
Some legacy systems. If integrating with a legacy system that requires DD/MM/YYYY or similar, you'll need to parse and reformat. But your internal storage should still be ISO 8601.
RFC 3339 — a stricter cousin
RFC 3339 is a profile of ISO 8601 used by the Internet Engineering Task Force. It's slightly stricter:
- Always 4-digit year, 2-digit month, etc.
- Always 'T' separator (no space)
- Always 'Z' or numeric offset (no abbreviations)
- Always include seconds (no shorter forms)
For most APIs, RFC 3339 is what you want. ISO 8601 is broader; RFC 3339 is the practical standard.
Common file uses
ISO 8601 is the right format for:
- Database columns of type `timestamp` or `timestamptz`
- JSON API responses — always quote-wrapped strings
- CSV exports for time data
- Filenames that include dates: `report-2026-05-21.csv`
- Log files — most logging libraries default to ISO 8601
- Calendar (.ics) files — ISO 8601 with specific extensions
- Configuration files for scheduling
FAQ
Is ISO 8601 the same as YYYY-MM-DD?
YYYY-MM-DD is a subset of ISO 8601 (just the date portion). Full ISO 8601 includes datetime and time-zone information.
Why YYYY-MM-DD instead of MM-DD-YYYY?
Because it sorts correctly. With YYYY-MM-DD, alphabetical sort gives chronological sort. With MM-DD-YYYY, alphabetical sort would group all Januaries together regardless of year.
Can I use slashes instead of dashes?
ISO 8601 specifies dashes. `2026-05-21` is valid; `2026/05/21` is not. Most parsers accept slashes anyway, but for strict compliance, use dashes.
Can I write `T` lowercase?
ISO 8601 specifies uppercase `T`. Most parsers accept lowercase `t` but uppercase is preferred.
Are seconds required?
Not strictly. ISO 8601 supports `YYYY-MM-DDTHH:MM` (no seconds). For network APIs, RFC 3339 requires seconds.
What about milliseconds?
Optional in ISO 8601: `YYYY-MM-DDTHH:MM:SS.sss`. Some systems use 3 decimal places, others use 6 (microseconds) or 9 (nanoseconds). Match what your system requires.
Why doesn't ISO 8601 include time zone names?
Because time zone names like "EST" are ambiguous (Indian Standard Time? Eastern Standard Time?). ISO 8601 uses numeric offsets, which are universal. For time zone names, use IANA names (`America/New_York`) — separate from ISO 8601 timestamps.
Bottom line
ISO 8601 is YYYY-MM-DD with optional time and timezone information. It's sortable, unambiguous, and universally supported. Use it for all internal data storage, APIs, and machine-readable date representations. Use prose formats only for human-readable text.
For converting between ISO 8601 strings and Unix timestamps, the epoch converter handles them in both directions.