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.
Related tools
- Timestamp Converter works with Unix times in either direction.
- strftime Builder builds custom format strings.
- ISO 8601 Duration Calculator handles lengths of time.
- Cron Expression Parser explains scheduled run times.
Checked against the current version of the RFC 3339 Timestamp Converter on .

