How does RFC 3339 differ from ISO 8601?

RFC 3339 mandates the full date-time form with a literal T separator, a colon in the offset, and either Z or a signed numeric offset. ISO 8601 allows omitting the colon, using a space separator, and other variants RFC 3339 forbids.

Why must the offset be explicit?

RFC 3339 was designed for unambiguous machine parsing. A bare local time has no defined meaning, so every value carries either Z or an explicit ±HH:MM offset.

How many fractional-second digits should I use?

Three is conventional for milliseconds (compatible with JavaScript Date.toJSON), six for microseconds (matches PostgreSQL timestamptz), nine for nanoseconds (Go's time.RFC3339Nano).

Is the date data sent anywhere?

No. All conversion happens locally; nothing is logged or transmitted.

rfc 3339 · iso 8601 · strict · http · api

Convert dates to RFC 3339 form

RFC 3339 is the strict ISO 8601 subset used by HTTP, OpenAPI, Slack, and GitHub. Always has T separator and an explicit timezone. Runs locally.

Quick Start

How RFC 3339 differs from ISO 8601

ISO 8601 allows lots of variants. RFC 3339 picks one strict profile for the internet: full-date "T" full-time with an explicit timezone (Z or ±HH:MM). No basic format, no week dates.

01
Paste any date
ISO, RFC 2822, or whatever JavaScript's Date parser handles.
Parsing accepts ISO 8601, RFC 3339, RFC 2822, and Unix epoch seconds/milliseconds. The Date constructor handles the rest with browser-engine consistency.
inputISO 8601RFC 3339epochlive
in · timestampany · ISO
```
2026-05-21T12:00Z
```
loaded · ISO 8601zone · ready
02
Six emits
Z, +00:00, no-fraction, with-ms, with-µs, date-only — all valid RFC 3339.
All math runs in UTC internally to avoid DST landmines; presentation converts back to the user’s zone via Intl.DateTimeFormat.
variantsUTC mathIntlDST-safelive
out · options6 · live
```
Z · +00:00 · date
```
options applied · UTCDST-safe
03
Pick the right one
OpenAPI date-time prefers Z; some APIs require explicit +00:00 over Z.
Output respects the chosen timezone offset (Z vs +05:30) and pads digits per ISO conventions so sorts stay chronological.
pickoffsetzone-awaresortablepadded
rule · computedspec · ready
```
+00:00
```
computed · instantsortable
04
Copy any one
Each row has its own copy button — grab the exact form your endpoint wants.
Copy writes via the Async Clipboard API; nothing pings a time server — the browser’s clock is the only oracle.
copyclipboardno oracledeterministicclient-side
✓ · copiedready · done
```
✓ Copied
```
shipped · ready to shipsuccess

Pro tips

Time math without DST landmines

Always store UTC

Convert to local for display only. UTC storage avoids DST jumps and timezone drift in databases.

Watch leap seconds

POSIX time doesn’t count leap seconds; some systems do. Don’t use timestamps for sub-second precision across boundaries.

Prefer Temporal eventually

The Date API has many quirks. Temporal is shipping in modern engines and handles zones correctly.

Cron is timezone-tricky

Cron expressions run in the daemon’s local zone unless told otherwise. Pin a TZ explicitly for predictable runs.

ISO 8601 sorts naturally

YYYY-MM-DDTHH:mm:ss sorts correctly as a string. Don’t use US-style MM/DD/YYYY for anything machine-readable.

Beware Y2K38

Signed 32-bit Unix timestamps overflow in 2038. Use 64-bit storage end-to-end for long-lived systems.

Use Cases

When to use RFC 3339

OpenAPI, JSON APIs, HTTP headers.

OpenAPI dates

format: date-time is RFC 3339 by spec. Math runs in UTC under the hood to dodge DST jumps — local time is only for display. That means scheduling logic and date diffs survive March / November fall-back without the classic off-by-one-hour bug.

DST-safe

Slack / GitHub

Both webhook payloads use Z-suffixed RFC 3339. Browser clock is the only source — no external time server, no privacy leak, no rate limit. Pair with NTP-synced server time for high-accuracy use cases, but for human-scale work the browser clock is plenty.

UTC-correct

If-Modified-Since

Some new HTTP APIs prefer RFC 3339 over RFC 1123 dates. ISO 8601 output sorts naturally as strings, perfect for filenames (report-2026-01-15.pdf) and log lines that need chronological ordering without parsing. Drop into S3 keys for free time-bucketing.

ISO-sortable

Compliance logs

Audit logs that need an unambiguous, sortable timestamp. Pairs cleanly with cron, scheduled tasks, and timestamped log analysis. The tool's output drops directly into APScheduler, Linux cron, or GitHub Actions schedule expressions without re-formatting.

spec-grade

Cross-locale storage

Avoid the 04/05 vs 05/04 ambiguity in DBs. Output respects the chosen timezone offset (Z vs +05:30) so REST APIs and database TIMESTAMP WITH TIME ZONE columns round-trip cleanly. No ambiguity between "noon UTC" and "noon local".

i18n

Generic JSON

Default to RFC 3339 when designing a new REST endpoint. Confirms the difference between epoch seconds (10 digits) and milliseconds (13 digits) before you commit code that mis-multiplies by 1000 — a classic bug in cross-language time handling.

epoch-accurate

FAQ

Frequently asked questions

Z vs +00:00?

Both are valid RFC 3339; Z is shorter. Some validators are picky — check your spec.

Can I drop fractional seconds?

Yes — RFC 3339 allows 0, 3, 6, or 9 digits of fractional seconds. The 'no fractional' variant strips them.

Why microseconds with 6 digits?

Some Postgres / Python systems emit microsecond precision. RFC 3339 permits any digit count past the decimal.

Date only?

RFC 3339 calls it full-date — YYYY-MM-DD. Use when time of day is irrelevant.

Is anything sent to a server?

No — conversion runs locally in your browser tab.

Suggest a tool

Something missing?

Tell us what you need. We ship the top requests every two weeks.

47 in queue·8 shipped this month

Request queued. Thanks!