RFC 3339 vs ISO 8601

Two standards, one clear winner for internet data — understanding the relationship between ISO 8601 and RFC 3339

If you have ever worked with APIs, databases, or any system that deals with dates and times, you have almost certainly encountered ISO 8601 and RFC 3339. These two standards define how dates and times should be formatted as strings, and while they are closely related, they serve different purposes and have important distinctions that can trip up even experienced developers.

What Is ISO 8601?

ISO 8601 is an international standard published by the International Organization for Standardization. It defines a broad set of rules for representing dates and times as text. The full standard is extensive and covers many formats, including date-only representations, time-only representations, durations, intervals, and week dates.

The most commonly used ISO 8601 formats include:

The flexibility of ISO 8601 is both its strength and its weakness. Because so many variations are valid, parsing ISO 8601 strings can be ambiguous. A date-only string like 2026-07-22 is perfectly valid ISO 8601, but it contains no time information. This ambiguity makes ISO 8601 insufficient for many technical applications where every timestamp must be complete and unambiguous.

What Is RFC 3339?

RFC 3339 was published in 2002 by the Internet Engineering Task Force (IETF). It is a strict profile of ISO 8601 designed specifically for use on the internet. The key difference is that RFC 3339 restricts ISO 8601 to a single, unambiguous format that always includes both date and time with a mandatory time zone offset.

A valid RFC 3339 timestamp must include:

Examples of valid RFC 3339 timestamps:

Key Difference

Every valid RFC 3339 timestamp is also valid ISO 8601, but not every valid ISO 8601 string is valid RFC 3339. RFC 3339 is a subset that guarantees a complete, unambiguous datetime with time zone information.

Side-by-Side Comparison

Here is a direct comparison of common formats and their validity under each standard:

Date Only

2026-07-22 — Valid ISO 8601, not valid RFC 3339. RFC 3339 requires a full datetime with time zone.

Date and Time Without Time Zone

2026-07-22T14:30:00 — Valid ISO 8601, not valid RFC 3339. The time zone offset is mandatory in RFC 3339.

Date and Time With UTC

2026-07-22T14:30:00Z — Valid under both standards. The Z suffix indicates UTC and is allowed by both.

Basic Format Without Separators

20260722T143000Z — Valid ISO 8601 basic format, not valid RFC 3339. RFC 3339 requires hyphens and colons.

Space Separator Instead of T

2026-07-22 14:30:00Z — Valid ISO 8601 (space is an allowed literal replacement for T), not valid RFC 3339. RFC 3339 mandates the T character.

Where Each Format Is Used

RFC 3339 in Practice

RFC 3339 is the standard choice for modern APIs and web services. Google APIs, GitHub, Stripe, Slack, and virtually all REST APIs use RFC 3339 for their datetime fields. JSON Schema specifies RFC 3339 as its date-time format. The reason is simple: it eliminates parsing ambiguity. When every timestamp looks the same, code can reliably parse and format dates without special handling for dozens of edge cases.

Programming languages and libraries have also standardized on RFC 3339 parsing. Go's time.RFC3339 constant, Python's datetime.fromisoformat() (in Python 3.11+), and JavaScript's Date.toISOString() all produce RFC 3339 output.

ISO 8601 in Practice

ISO 8601 is used more broadly outside of internet protocols. Filenames and directory structures often use ISO 8601 date stamps like 2026-07-22 for sorting. Database columns of type DATE use the ISO 8601 date format. Log files, configuration files, and human-readable displays often use parts of ISO 8601 without the full datetime-timezone combination that RFC 3339 requires.

The ISO 8601 basic format (without separators) is commonly used in barcodes and other machine-readable contexts where every character counts. Healthcare systems, government documents, and international trade frequently reference ISO 8601 for date representation.

Common Pitfalls

One of the most frequent mistakes is assuming that a library that claims to parse ISO 8601 will handle any valid ISO 8601 string. Most libraries actually implement a subset, often closer to RFC 3339. For example, a parser that only handles the T separator and requires offsets will reject valid ISO 8601 strings that use spaces or omit time zones.

Another common issue is timezone handling. UTC is sometimes represented as Z and sometimes as +00:00. Both are valid in RFC 3339, but some systems only accept one or the other. It is always safest to normalize your timestamps to use Z for UTC when storing or transmitting data.

Leap seconds add another layer of complexity. ISO 8601 allows the time 23:59:60 to represent a leap second, but RFC 3339 does not explicitly address them. Most systems simply do not support leap seconds, and timestamps like 23:59:60 will be rejected by standard parsers.

Which One Should You Use?

The answer depends on your context:

Best Practice

When in doubt, use RFC 3339 with the Z suffix for UTC. Store all timestamps in UTC and convert to local time only at display time. This approach avoids daylight saving time issues and makes comparisons straightforward.

Converting Between Formats

If you need to convert between RFC 3339 and ISO 8601 formats, most programming languages make this straightforward. In JavaScript, new Date().toISOString() outputs RFC 3339. In Python, datetime.now(timezone.utc).isoformat() produces an ISO 8601 string that is also RFC 3339 compliant when the time zone is included.

For bulk conversions, you can use our date format converter to paste any date string and see it represented in multiple formats simultaneously.

Explore Related Topics

Continue learning about time and timekeeping

ISO 8601 Deep Dive

The complete ISO 8601 standard explained

Unix Timestamp

Understanding epoch-based time

Epoch Timestamp

How computers count time

Epoch Converter

Convert between timestamps and dates