Gera Tools

RFC-3339 Date Converter

Convert between RFC-3339 timestamp strings and other formats

Free RFC-3339 date converter. Validate and decode an RFC-3339 timestamp into Unix epoch seconds, milliseconds and ISO-8601 UTC, or build an RFC-3339 string from a date. Runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is RFC-3339?

RFC-3339 is the Internet date-time profile of ISO-8601 used by JSON APIs, logs and many protocols. It requires a full date and time and a timezone (Z or ±hh:mm), for example 2023-11-14T22:13:20Z.

RFC-3339 is the timestamp format you meet most often in modern APIs: it is the strict, unambiguous profile of ISO-8601 that JSON, logging systems and many Internet protocols standardise on. A compliant value such as 2023-11-14T22:13:20Z always carries a full date, a full time, and an explicit timezone. This converter validates RFC-3339 strings and translates them to Unix time and back, locally in your browser.

How it works

The tool first checks the string against an RFC-3339 grammar that requires every mandatory part:

date-fullyear "-" date-month "-" date-mday "T"/" " hh ":" mm ":" ss [".".frac] (Z | ±hh:mm)

If the structure is valid, it hands the value to Date.parse to compute the absolute instant in milliseconds, then derives:

const ms = Date.parse(input);
const seconds = Math.floor(ms / 1000);
const iso = new Date(ms).toISOString(); // canonical UTC

To build a compliant RFC-3339 string from any date, the tool parses your input and re-emits it as a UTC ...Z timestamp via toISOString(), which is itself valid RFC-3339.

RFC-3339 vs ISO-8601: the key differences

ISO-8601 is a broad international standard that allows many optional forms: date-only values, week dates, ordinal dates, times without timezones, and various separator styles. This flexibility is useful in human-readable documents but creates ambiguity in machine-to-machine communication — a parser receiving 2023-11 cannot know if it means November 2023 or the 11th day of an unspecified year.

RFC-3339 resolves this by defining a strict subset: every timestamp must include a full date, a full time to at least second precision, and an explicit timezone offset. The only formatting flexibility it permits is the separator between date and time (T or a single space) and an optional fractional seconds field. Any valid RFC-3339 string is also a valid ISO-8601 string, but the reverse is not true.

In practice, when an API documentation says “ISO-8601 timestamps,” it usually means RFC-3339. When building APIs or configuring logging systems, defaulting to RFC-3339 is the safer choice.

UTC vs offset timestamps: when each is appropriate

RFC-3339 permits both UTC (Z) and numeric offsets (+05:30, -08:00). They are interchangeable for identifying the same instant in time, but they carry different semantic content:

  • UTC (Z) — records only the absolute instant, with no claim about the local time where the event occurred. This is the right choice for machine timestamps: server logs, API responses, database timestamps, audit records.
  • Numeric offset — records both the absolute instant and the wall-clock offset, which preserves information about local time. This matters for user-facing events where “3pm local” has meaning beyond the UTC equivalent: a calendar appointment, a scheduled job, a user’s login time in their timezone.

For most backend systems, emit UTC. For anything representing a user’s local time (event scheduling, notification timing, document timestamps displayed to the user), preserve the offset.

Fractional seconds

RFC-3339 allows optional fractional seconds: 2023-11-14T22:13:20.500Z means 500 milliseconds past the whole second. The spec does not limit precision, but three decimal places (milliseconds) is the de facto standard in most systems. JavaScript’s Date.toISOString() always emits three decimal places, so timestamps generated from JavaScript are inherently RFC-3339 compliant.

Example

Decoding 2023-11-14T22:13:20Z gives:

  • Epoch seconds: 1700000000
  • Epoch milliseconds: 1700000000000
  • Canonical UTC: 2023-11-14T22:13:20.000Z

The offset form 2023-11-14T17:13:20-05:00 describes the same instant — local time five hours behind UTC — and converts to the identical epoch value. The converter shows this equivalence explicitly.

Common validation errors

  • Missing timezone — 2023-11-14T22:13:20 is valid ISO-8601 but invalid RFC-3339; this tool will flag it
  • Date-only string — 2023-11-14 is not an RFC-3339 timestamp; it lacks the time component
  • Non-standard separators — 2023/11/14 uses slashes, which are not valid in either ISO-8601 or RFC-3339

Tips:

  • Z and +00:00 are equivalent; both mean UTC
  • For interoperability, emit UTC (Z) timestamps; reserve numeric offsets for when local wall-clock context genuinely matters
  • When generating timestamps programmatically, new Date().toISOString() in JavaScript produces valid RFC-3339 in UTC