1. Home
  2. Developer tools
  3. RFC 3339 Timestamp Converter

RFC 3339 Timestamp Converter

Paste a timestamp in almost any common style and see the same moment as RFC 3339, an email Date header, an HTTP date, an ISO week date, a SQL timestamp and Unix time, in the zone you choose.

Free, no sign-up. Runs in your browser: nothing is uploaded.

How to use RFC 3339 Timestamp Converter

  1. Paste a date and time.
  2. Choose the output time zone.
  3. Copy any of the formats and read the validity check.

Features

  • Reads RFC 3339, ISO 8601, RFC 2822, HTTP and SQL styles
  • Eleven output formats including ISO week and ordinal dates
  • Any time zone, offset or named zone
  • Validates RFC 3339 and explains each problem
  • Says when the input had no zone
  • Unix seconds and milliseconds

Supported formats

Input

  • Timestamps

You get

  • RFC 3339
  • RFC 2822
  • ISO 8601
  • Unix time

Private by design

Everything you enter is processed by your browser on this device. Nothing is sent to openWorkstand or anyone else, so the RFC 3339 Timestamp Converter is safe for private and work data. After you have used it once while online, it also works without an internet connection. How local processing works

Good to know

  • Text without a time zone is read as UTC.
  • Free-form dates in languages other than English are not understood.

Guide

RFC 3339, ISO 8601 and RFC 2822: the same moment in every format

Dates are written in more ways than any other kind of data: two RFCs and an ISO standard define overlapping formats, databases add their own, and log files add more. Moving between them is routine work for anyone writing integrations. This page reads a timestamp in whichever style you have, shows the same instant in eleven formats, and tells you whether the input is valid RFC 3339.

The three standards

ISO 8601 is the broad international standard for dates and times, with calendar dates, week dates, ordinal dates, durations and many optional forms. RFC 3339 is a profile of it for the Internet: a full date, a T, a full time and a required zone, such as 2026-10-30T14:05:09+01:00. RFC 2822 is the format of email Date headers, like Fri, 30 Oct 2026 14:05:09 +0100, and HTTP uses a fixed variant in GMT. Each describes the same instants in a different shape.

Reading input

The page accepts RFC 3339 and the other ISO forms, including week dates such as 2026-W44-5 and ordinal dates such as 2026-303, RFC 2822 with named zones like GMT or EST, the HTTP date form, SQL timestamps with a space and plain dates. A line below the input says which format was recognised. If the text has no zone or offset, it is read as UTC, and the page states this, because other tools may read it as local time. Free-form text such as “next Friday” is not understood.

The output formats

For the instant you gave, the page shows RFC 3339 in the zone you pick, RFC 3339 in UTC, RFC 2822, the HTTP date, ISO 8601 basic form without separators, the ISO week date, the ISO ordinal date, an SQL timestamp, Unix seconds, Unix milliseconds and the JavaScript toISOString result. Choose this device’s zone, UTC, a fixed offset or a named zone for the formats that depend on it. Each row has a copy button.

Checking RFC 3339

The second panel tests the original text against the RFC 3339 grammar and lists problems in plain language: a missing zone, an offset written without a colon, a minute or second out of range, a date that does not exist such as 30 February, a lower-case t or z, a space in place of T, and the special offset -00:00. A second value of 60 is allowed because of leap seconds. “Yes: it is a valid RFC 3339 timestamp” appears when there is nothing to report.

A worked example

The Sample button loads 2026-10-30T14:05:09+01:00. In UTC it is 2026-10-30T13:05:09Z. The email form is Fri, 30 Oct 2026 14:05:09 +0100 if you choose the fixed offset +01:00, and Fri, 30 Oct 2026 13:05:09 +0000 if you choose UTC. The HTTP date is Fri, 30 Oct 2026 13:05:09 GMT, the ISO week date is 2026-W44-5, the ordinal date is 2026-303, and the Unix time is 1793365509 seconds. For the text 2026-10-30 14:05:09, which has a space and no zone, the page reads it as UTC and the checker reports two problems: the space instead of T, and the missing zone.

Limits

The page converts instants and does not know about time zone rules beyond what your browser provides, so named zones follow the browser’s database, which is usually current but not guaranteed. Dates before the year 1000 or very far in the future are not a priority. Local times that do not exist or occur twice at a daylight-saving change are not flagged. Locale-specific formats in other languages are not understood.

Checked against the current version of the RFC 3339 Timestamp Converter on .

Frequently asked questions

Is a timestamp with a space instead of the T valid?

RFC 3339 allows a space as a readability concession, but ISO 8601 and many parsers require the T. If you are writing for an API, use the T; if you are reading, expect both. The validity check on this page lists a space as a warning for that reason, since RFC 3339 itself permits it.

Why do APIs insist on a time zone in the timestamp?

Without it the moment is ambiguous: 14:05:09 could be any of up to 24 different instants. A Z or an offset such as +01:00 pins it to one. RFC 3339 requires it, and the page tells you when your input lacks one and was read as UTC.

What is the difference between RFC 3339 and ISO 8601?

RFC 3339 is a stricter profile of ISO 8601: it needs a full date and time and a zone, and allows a space instead of T. Every RFC 3339 timestamp is valid ISO 8601, but not the reverse.

What does -00:00 mean?

It says the local offset is unknown, while +00:00 or Z means the time is UTC. Many parsers treat them alike, but the difference is defined in RFC 3339.

Keep working with the result

openWorkstand also includes a free workspace with documents, spreadsheets, tasks, projects and a calendar that save to a folder on your computer.